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.
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 Update | On 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) |
| Operation | On Source Item | On Linked Item |
|---|---|---|
| Linked item create in state A as a result of copying |
|
|
Linked item update in state A and group G |
|
|
Linked item update with transition A-B and in group G |
|
|
Linked item update with transition A-B and between groups G-H |
|
|
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 template | Business 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:
Comments
Log in or register to comment.