Trigger
- 16 Apr 2024
- 6 Minutes to read
- Print
- PDF
Trigger
- Updated on 16 Apr 2024
- 6 Minutes to read
- Print
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
Trigger
A trigger lets you define when the Business Rule should execute. A trigger can be defined on creation and on updating of a task. A trigger can also be defined using After or Async Business Rules.
Trigger Type – Created & Updated
When the user creates a Business Rule, the user has the option to configure the Business Rule in two ways,
- Created: When a user configures a Business Rule with the Trigger type as on Created, the rule will trigger immediately once the ticket is created.
- Updated: When a user configures a Business Rule with the Trigger type as on Update, the rule will only be triggered when a user updates any fields or if the conditions are matched. (In this case the Business Rule will not trigger on creation of a new Incident even if the condition is matched).
The below infographic shows the two trigger types.
Figure: Created and Updated.
Let's explore the following use-cases to better understand the difference between Created and Updated.
Trigger Type | Use Case User Persona: Application Designer | Solution |
Created | Adam wants to have a rule created so that an incident where the Tenant is ‘IT’, Symptom is ‘Laptop Not Working’, and the Description is ‘Issues in rebooting Laptop’ gets automatically assigned to the Helpdesk workgroup. | The application designer Sam creates a Business Rule with the Trigger set to Created, then whenever the end user creates a new Incident, this Business Rule will trigger. This is an example of the use of Created Trigger Type. |
Updated | James wants to create a rule that should trigger only when an already created incident gets updated or reassigned to another user in a different Workgroup. | The application designer Sam creates a Business Rule with the Trigger set to Updated, then the Business Rule will trigger only when the incident gets reassigned to another user in a different Workgroup. This is an example of the use of Updated Trigger Type. |
The Trigger section enables you to select the Trigger Type for creating the Business Rule.
To create a Business Rule, select the Trigger Type and perform the following steps:
1. Select the Trigger Type for the Business Rule.
You can select the Trigger type as Created or Updated as shown below.
2. Under Process Business Rule, select when the Business Rule should be processed.
The Business Rule can be processed in After and Async mode. For more information on how to use After and Async see below.
3. Click Next.
After vs Async Business Rules
After Business Rule is used when a field needs to be updated and displayed immediately after the user submits a record. After Business Rule gets executed whenever the user submits a form and the data is saved in the database.
When selected, the After Business Rule will trigger once the Incident is created or updated. Also, the incident will be frozen i.e., no update will be allowed for the incident until the Business Rule is processed.
Let's explore the following use-case.
Use Case User Persona: Application Designer | Solution |
| Adam wants to configure a Business Rule in After, that automatically updates Category as ‘Laptop’ and Workgroup as ‘Hardware Team’ if the Symptom contains the word ‘Laptop’. | The application designer Sam will configure the rule in After, so that the system will auto-update the fields and the page will get frozen till the update is carried. This ensures no other user can overwrite the changes to the fields that need to be updated. |
Async Business Rule is processed asynchronously and runs in the background. In the case of Async, the Incident will not be frozen, and the rule will run in the background. Running on background means that the user can proceed with other functionality and code will run on the background which will not impact the user while doing other transitions.
Async Business Rule is required when some tasks need to be performed in backend for updating some table data etc and the user need not know about. Async Business Rule runs in the background simultaneously with other processes.
Let's explore the following use-case.
S.No. | Use Case User Persona: Application Designer | Solution |
1 | Rosy is trying to configure a Business Rule to notify the head of IT & Server Team whenever there is a P1 Incident for 'Server' Category. | The application designer Sam has configured this rule in Async. Since the Business Rule has been configured in Async, the Incident page does not get frozen, and the recipients will get notified in the background as long as the conditions are met. This is how you can use the Business rule in Async. |
Difference between After and Async Business Rule
Let's have a look at the differences between After and Async Business Rules with some examples.
After Business Rule | Async Business Rule |
Rules are executed synchronously. | Rules are executed asynchronously.
|
After Business Rule is used when some fields need to be updated and displayed to the user immediately after user saves the record. | An Async Business Rule is necessary when certain backend tasks, like updating data in other tables, need to be performed without the user being informed or affected by the background processes. |
Freezes the record and restricts any changes to be performed. | Does not freeze the record and performs the actions in back-end.
|
Example:
| Example: 1. To create an event & send notification. User changes some field, based on that an event must be created, and notification sent to user. 2. To calculate the SLA. |
When NOT to use After and Async (Examples)
Incorrect use of After Business Rule
Scenario: Adam, an Analyst wants to update 100 Incident records simultaneously using a Business Rule.
As this operation would generally take a longer duration to complete, an end user/customer would not want to wait until this operation gets completed.
Right | This task should Ideally be performed in Async Business Rule as we give the control to the user, but action is performed at the back end. This can be done for non-critical tasks such as for sending notifications and Calculating the SLA. |
Wrong .jpg?sv=2022-11-02&spr=https&st=2024-12-22T08%3A59%3A08Z&se=2024-12-22T09%3A09%3A08Z&sr=c&sp=r&sig=qnz5xz%2FiXvls4oyJQjJSL8T62tvmyu1m4KL5y8hzMWE%3D) | If Adam configures such a Business Rule in After, then the users must wait till updates on 100 records are completed before they can resume working on the record. Hence this is not an ideal use of this Rule. |
Incorrect use of Async Business Rule
Scenario: Rosy, an Analyst, wants to update the short description of an Incident using Business Rules.
Right | This task should Ideally be performed using After Business Rule. Hence if the users are trying to update the short description, the control will be taken away from the user and the action will be performed, post which the control will be transferred back to the user. This will help in avoiding multiple entries in the database and ensure that all the users are seeing the same short description at once.
|
Wrong | If Rosy performs this Business Rule in Async, the changes will happen asynchronously on every user’s machine. So, while a user might have already updated the short description on their machine, it might appear differently on another user’s machine.
|
(1).jpg?sv=2022-11-02&spr=https&st=2024-12-22T08%3A59%3A08Z&se=2024-12-22T09%3A09%3A08Z&sr=c&sp=r&sig=qnz5xz%2FiXvls4oyJQjJSL8T62tvmyu1m4KL5y8hzMWE%3D)
.jpg?sv=2022-11-02&spr=https&st=2024-12-22T08%3A59%3A08Z&se=2024-12-22T09%3A09%3A08Z&sr=c&sp=r&sig=qnz5xz%2FiXvls4oyJQjJSL8T62tvmyu1m4KL5y8hzMWE%3D)
Use Business Rules with Caution
Business Rules are intended to address common actions. Compared to what a developer can do by using form scripts, Business Rules have their limitations.
Caution
Creating redundant and too many Business Rules can have a performance impact on your application. Apex recommends having regular checks and consolidating redundant Business Rules into a single rule whenever possible. In addition, Business Rules that are not being used should be removed to avoid redundancy.Having too many or redundant Business Rules can have a negative impact on the Apex application as the system will need to compute and address all the Business Rules that have been configured before performing any action. Hence it is advised to use Business Rules in an efficient manner to get the best outcome of using them in your organization.
Was this article helpful?