Processing of Business Rules having After Save trigger

The following topics are provided:

Understand the processing of business rules having After Save trigger

This topic explains how the system processes business rules having the After Save trigger.

  • The following diagram illustrates how After Save rules process when a Ticket is created manually, through email, through web services, or through another automated process.
  • The following diagram illustrates how After Save rules process when a Ticket is updated manually or updated by a rule in a previous round.

    Notes

    • Round: Each run from first rule to last rule is referred to as a round.
    • Chain: A series of rounds is referred to as a chain. 


Note

When the On Update By User Or Rule option is selected instead of the On Update By User option, if the last update was made by a user and not by a rule, the system performs a round to evaluate the criteria of all such rules. After the system has gone through all the rules once, the system stops, because there would be no further updates by a user, but only by rules.

Example

Consider a scenario where there are 10 rules. Out of the 10 rules, five rules have the On Create option and five rules have the On Update By User Or Rule option.

When you create a new ticket, the business rules are processed. If one of the rules containing the On Update By User Or Rule option is evaluated, which results in updating a ticket, the system checks all the rules one by one again. The system stops this process only when no updates are made to a ticket.

If one of the rules using the On Create option runs and causes an update, then a new round of rules will run and all rules will be evaluated again from top to bottom. Only those using the On Update By User Or Rule option will possibly run in the 2nd or subsequent rounds.

Note

If you select both the options On Update By User Or Rule and On Update By User, the option On Update By User Or Rule comes into effect and the rule is always triggered.

Note

From FootPrints 2019 Release 02, if business rules, that have After Save trigger, are triggered by a rule, FootPrints performs the Create New Record actions. However, this continues only for two iterations. After the third iteration, the application detects and blocks it as a potential recursive action leading to unintended behavior.


Triggering sequence considerations 

You can have rules defined and associated with different parts of your workflows (states, transitions, groups, and entire workflows).

The order in which the system processes rules depends on the internal ordering of rules based on triggers and on administrator-defined ordering.

It is important to order your rules properly, taking into account how the rules relate to each other.

Triggers are processed in the following order.

On UpdateOn Create

1. On Exit (for State)

1. On Enter

2. On Exit (for Group)

2. On Create as part of a copy/move operation

3. On Transition

3. After Save (On Create)

4. On Enter (for Group)

5. On Enter (for State)

6. Updated in State or Group (for State)

7. Updated in State or Group (for Group)

8. Updated in any State

9. Updated in any Group

10. On any Transition

11. After Save (On Update By User Or Rule)

 
For linked records, the system processes rules in production as shown in the following table. In addition, Administrators should set the order for rules attached to the same part of a record definition. The best way to update the triggering order is on the Business Rules page. View the rules in the Expanded View, expanding the nodes to see the rules you want to re-order and then change the settings in the Order column. For detailed instructions, see Configuring business rules.
OperationOn Source ItemOn Linked Item
Linked item create in state A as a result of copying
  1. Upon Item Copy
  2. On Linked Item Create
  1. On Enter (on A)
  2. On Create as part of a copy/move operation
  3. After Save (On Create)

Linked item update in state A and group G

  1. On Linked Item Update
  1. Updated in State or Group (on A)
  2. Updated in State or Group (on G)
  3. Updated in any State
  4. Updated in any Group
  5. After Save (On Update By User Or Rule)

Linked item update with transition A-B and in group G

  1. On Linked Item Update
  1. On Exit (on A)
  2. On Transition (on A-B)
  3. On Enter (on B)
  4. Updated in State or Group (on G)
  5. On any Transition
  6. Updated in any Group
  7. After Save (On Update By User Or Rule)

Linked item update with transition A-B and between groups G-H

  1. On Linked Item Update
  1. On Exit (on A)
  2. On Exit (on G)
  3. On Transition (on A-B)
  4. On Enter (on H)
  5. On Enter (on B)
  6. On any Transition
  7. After Save (On Update By User Or Rule)

Example of how inherited fields in quick ticket templates work when after save rules change field values

If an After Save business rule is applied on a record created by using a master template with linked sub task, before the sub task is created, the After Save rule is executed first. In this case, if the fields of the master task are updated, the fields in the subtask configured to inherit will get the values from the master that were updated by the rule.

To understand this, configure the following templates and business rule:

Master template Subtask templateBusiness rule

Priority=Critical

Status=Open

Department=IT

Priority (inherit)

Status (inherit)

Department (inherit)

After Save Rule:

Trigger: On Create

Criteria: Department=IT; Issue Type=Software

Action: Set Field Value

Method: Set Field Value

Field: Priority

Value: Medium

Create a ticket with the following values:

Master ticket 1:

Priority=Critical

Status=Open

Department=IT

Issue Type=Software

Subtask ticket 1:

Priority=Medium

Status=Open

Department=IT

Master ticket 2:

Priority=Critical

Status=Open

Department=IT

Issue Type=Network

Subtask ticket 2:

Priority=Critical

Status=Open

Department=IT

For master ticket 1 after save rules changed value of the Priority field before the subtask is created, the subtask ticket has the updated value of the Priority field.

For master ticket2 the after save rule criteria is not met, the subtask ticket is created with inherited values from the master ticket.

Note

Subtask tickets are created after the first round of rules are run on the master ticket so fields that get updated in the subsequent rounds of rules are not inherited by the subtasks.

Example: Configuring business rule to send an email message on ticket creation

This video (5:18) provides information about how to configure a business rule to send an email on ticket creation in FootPrints.



Was this page helpful? Yes No Submitting... Thank you

Comments