Order of Execution in Salesforce Explained

Order of Execution in Salesforce Explained.

1. What is Order of Execution in Salesforce?

Order of Execution in Salesforce is the order in which Salesforce performs events when you save a record in Salesforce.

2. Order of Execution in Salesforce

2.1 Order of Execution in Salesforce – Client Side (Browser)

Browser runs JavaScript validation if the record contains any dependent picklist fields. The validation limits each dependent picklist field to its available values. No other validation occurs on the client side. If the validation passes Server performs event in the order mentioned in the next section.

2.2 Order of Execution in Salesforce – On the (Salesforce) Server

1. Loads the original record from the database or initializes the record for an upsert statement

2. Loads the new record field values from the request and overwrites the old values

If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:

Compliance with layout-specific rules
Required values at the layout level and field-definition level
Valid field formats
Maximum field length

When the request comes 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 do not refer to the object itself.

Salesforce runs custom validation rules if multiline items were created, such as quote line items and opportunity line items.

3. Executes record-triggered flows that are configured to run before the record is saved

4. Executes all before triggers

If you have more than one trigger for the same object the order of execution of triggers will be random. It is a best practice to create only one trigger per object to avoid any undesired outcomes due to trigger order being random.

5. Runs System Validations

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.

6. Executes duplicate rules

If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.

7. Saves the record to the database, but doesn’t commit yet.

8. Executes all after triggers

If you have more than one trigger on the same object trigger order execution is random.

9. Executes assignment rules

10. Executes auto-response rules

11. 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 are not 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)

12. Executes escalation rules

13. Executes the Salesforce Flow automations

Executes the following 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.

14. Executes entitlement rules

15. Executes after save record triggered flows

16. Roll-up summary calculation

If the 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 parent record. Parent record goes through save procedure.

17. Grand parent roll-up summary calculation

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 save procedure.

19. Commits all DML operations to the database

20. Executes post commit logic

After the changes are committed to the database, executes post-commit logic such as sending email and executing enqueued asynchronous Apex jobs, including queueable jobs and future methods.

Note: Note: During a recursive save, Salesforce skips steps 9 (assignment rules) through 17 (roll-up summary field in the grandparent record).

3. Additional Considerations for Order of Execution in Salesforce

Order of Execution in Bulk DML
- 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.
Order of Execution for AccountContactRelation
- When you insert a non-private contact in your org that associates a contact to multiple accounts, an AccountContactRelation is created and its validation rules, database insertion, and triggers are executed immediately after the contact is saved to the database.
- When you change a contact’s primary account, an AccountContactRelation may be created or edited, and the AccountContactRelation validation rules, database changes, and triggers are executed immediately after the contact is saved to the database.
Order of execution when you’re using before triggers to set Stage and Forecast Category
- If you set Stage and Forecast Category, the opportunity record contains those exact values.
- If you set Stage but not Forecast Category, the Forecast Category value on the opportunity record defaults to the one associated with trigger Stage.
- If you reset Stage to a value specified in an API call or incoming from the user interface, the Forecast Category value should also come from the API call or user interface. If no value for Forecast Category is specified and the incoming Stage is different than the trigger Stage, the Forecast Category defaults to the one associated with trigger Stage. If the trigger Stage and incoming Stage are the same, the Forecast Category is not defaulted.