Trigger Order of Execution
Chapter Topics
- Basics of Triggers
- When to use triggers
- Types of Apex Triggers in Salesforce
- Trigger Order of Execution
- Trigger Context Variables in Salesforce
- Trigger.new in Salesforce| Context Variables in Apex Triggers
- Trigger.old in Salesforce | Context Variables in Apex Triggers
- Trigger.newMap in Salesforce| Context Variables in Apex Triggers
- Trigger.oldMap in Salesforce| Context Variables in Apex Triggers
- Trigger Exceptions
- Best Practice in Triggers
- Trigger Helper Class Pattern
Trigger Order of Execution In Apex
Whenever a record is saved with an update, insert, or upsert statement attached, the trigger execution order in Salesforce is determined. This order is the sequence in which the events will occur per the set criteria. Client-Side validation also occurs for records that contain any dependent picklist fields. This happens before the events occur on the server. The validation limit ensures that the picklist fields are restricted only to the available values.
Trigger order of execution example:
Salesforce Order of Execution
In Salesforce, there is a particular order of execution whenever a record is changed or inserted. The following are the steps of trigger execution:
Step 1: Load an original record from an existing database.
Step 2: Overwrite the old record values with the new values.
| If the request is from | Validation check to be performed |
| A standard UI edit page | Compliance with layout-specific rules Required values at the layout level and field-definition level Valid field formats Maximum field length |
| A User object on a standard UI edit page, | Runs custom validation rules |
| Multiline item creation, such as quote line items and opportunity line items | Runs custom validation rules |
| An Apex application or a SOAP API call | Salesforce validates only the foreign keys and restricted picklists |
Step 3: Execute all before triggers.
Step 4: Run all the user-defined and system validation rules.
Step 5: Save the record to the database, but do not commit the record.
Step 6: Execute all after triggers.
Step 7: Execute the assignment rules.
Step 8: Execute the auto-response rules.
Step 9: Execute the workflow rules.
Step 10: If there are workflow rules that result in field updates. Execute the field updates.
Step 11: If the record was updated via a workflow field update, execute the before and after triggers on the object in the context again, but only once.
Step 12: Execute the processes and flows on that record.
Step 13: Execute the escalation rules.
Step 14: Update the roll-up summary fields & cross-object formula fields.
Step 15: Repeat the same process with the affected parent or grandparent records.
Step 16: Evaluate criteria-based sharing rules.
Step 17: Commit all DML operations to the database.
Step 18: Execute post-commit logic such as sending emails.
Consideration for Trigger Order of Execution
There are some things to keep in mind during the trigger order execution to ensure system performance.
- The trigger.old does not run the workflow for a newly updated field triggered by a record update. For example, if a record field value is 2 and you update it to 6, the workflow field update will reflect the change as 6 . But in the update trigger that fires after the workflow field update, the field value obtained from Trigger.old is the original value of 2, and not 6.
- Triggers can take action at each attempt if they are part of the same DML call. This happens because there is no change to the transactions or to the static class variables accessed by the trigger.
- When multiple triggers are defined for the same event, the execution order is not defined.
- In API version 53.0 and earlier, after-save record-triggered flows run after entitlements are executed.
Need more support?
Get a head start with our FREE study notes!
Learn more and get all the answers you need at zero cost. Improve your skills using our detailed notes prepared by industry experts to help you excel.
