When you build a solution in Salesforce, you need to use DML operations to save, update, or upsert. So, you need to go below the surface and understand the order of execution otherwise your solutions end up creating unintended technical issues or you may start finding fatal errors due to exceeding limits.
When you save a record, it goes through a series of steps before the record gets saved. Before salesforce executes these events, the browser runs JavaScript validation if the record contains any dependent picklist fields.
If you are a salesforce consultant, architect, and developer, it's essential for you to understand the Order of Execution.
Let's Dive into deep:
- What is the Order of Execution?
- How does Order of Execution work?
- Order of Execution with detailed explanation.
- Additional Considerations
- Summary
- References
What is the Order of Execution?
When you insert, update, or upsert a record, Salesforce performs certain events in an orderly manner. It is nothing but a set of rules that govern when you try to update or insert any record or a Path that travels from multiple automation, processes, trigger, or other events happening from SAVE to COMMIT.
How does Order of Execution work?
Here is the Order of Execution:
1. System Validation Rules
2. Apex Before Triggers
3. Custom Validation Rules
4. Duplicate Rules
5. Apex After Triggers
6. Assignment Rules
7. Auto-Response Rules
8. Workflow Rules
9. Processes
10. Escalation Rules
11. Roll-Up Summary Fields
12. Commits all DML operations to the database
13. Executes post-commit logic, such as sending an email
Order of Execution with Detailed Explanation:
- On the server, Salesforce performs events in this sequence.
- Loads the original record from the database or initializes the record for an upsert statement.
- Loads the new record field values from the request and overwrites the old values.
Salesforce performs different validation checks depending on the type of request.
- For requests from a standard UI edit page, Salesforce runs these system validation checks on the record:
- Compliance with layout-specific rules
- Required values at the layout level and field-definition level
- Valid field formats
- Maximum field length
- Additionally, if the request is from a User object on a standard UI edit page, Salesforce runs custom validation rules.
- For requests from multiline item creation such as quote line items and opportunity line items, Salesforce runs custom validation rules.
- For requests from other sources such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Before executing a trigger, Salesforce verifies that any custom foreign keys don’t refer to the object itself.
- Executes record-triggered flows that are configured to run before the record is saved.
- Executes all before triggers.
- Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any custom validation rules. The only system validation that Salesforce doesn't run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
- Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record isn’t saved and no further steps, such as after triggers and workflow rules, are taken.
- Saves the record to the database, but doesn't commit yet.
- Executes all after triggers.
- Executes assignment rules.
- Executes auto-response rules.
- Executes workflow rules. If there are workflow field updates:
- Updates the record again.
- Runs system validations again. Custom validation rules, flows, duplicate rules, processes, and escalation rules aren’t run again.
- Executes before update triggers and after update triggers, regardless of the record operation (insert or update), one more time (and only one more time)
- Executes escalation rules.
- Executes these Salesforce Flow automations, but not in a guaranteed order.
- Processes
- Flows launched by processes
- Flows launched by workflow rules (flow trigger workflow actions pilot)
When a process or flow executes a DML operation, the affected record goes through the
save procedure.
- Executes record-triggered flows that are configured to run after the record is saved.
- Executes entitlement rules.
- If the record contains a roll-up summary field or is part of a cross-object workflow, perform calculations and update the roll-up summary field in the parent record. Parent record goes through the save procedure.
- If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the grandparent record. Grandparent record goes through the save procedure.
- Executes Criteria Based Sharing evaluation.
- Commits all DML operations to the database.
- After the changes are committed to the database, executes post-commit logic is executed. Examples of post-commit logic (in no particular order) include:
- Sending email
- Enqueued asynchronous Apex jobs, including queueable jobs and future methods
- Asynchronous paths in record-triggered flows
Additional Considerations:
- If a workflow rule field update is triggered by a record update, Trigger.old doesn’t hold the newly updated field by the workflow after the update. Instead, Trigger.old holds the object before the initial record update was made. For example, an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, and not 10.
- If a DML call is made with partial success allowed, triggers are fired during the first attempt and are fired again during subsequent attempts. Because these trigger invocations are part of the same transaction, static class variables that are accessed by the trigger aren't reset.
- If more than one trigger is defined on an object for the same event, the order of trigger execution isn't guaranteed. For example, if you have two before insert triggers for Case and a new Case record is inserted. The firing order of these two triggers isn’t guaranteed.
References:
Comments