Salesforce order of execution domino

Salesforce Order of Execution – A Pictorial View

Salesforce operates on robust system practices that ensure the platform is stable and runs smoothly without issues especially when customizations are added to it.

It does this by enforcing governor limits on each instance as well as by processing automation on data records in a defined order. This is most commonly known as order of execution.

What is Order of Execution and Why is it important?

Order of execution is, as the name states, an order defined by Salesforce according to which different automation processes are run when a single or bulk records are inserted or updated on an Object.

This is to ensure a proper sequence is followed when executing an insert, update or upsert on a record/s.

The following infographic takes you step by step on which processes run first and which processes follow after until the record is committed to the database.

Salesforce Order of ExecutionSalesforce Order of Execution

Explained

Let’s look at a detailed explanation of each step in the infograph above to get more context.

  1. First things first, the original record is loaded from the database or initialized for an upsert statement.
  2. The new field values are loaded by overwriting the old values and Salesforce runs system validation (If the request came from a standard UI edit page) to check the record for:
    • Layout-specific rules such as Required values at the layout level and field-definition level
    • Valid field formats or Maximum field length
  3. Before Trigger Flows are executed that are configured to run before the record is saved.
  4. Next, all Apex Before Triggers are executed.
  5. Salesforce runs system validation steps again, such as verifying that all required fields have a non-null value, and then runs any custom validation rules.
  6. Duplicate rules are executed after custom validation rules.
    • Note: 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. The record  is saved to the database, but doesn’t commit yet.
  8. All after apex triggers are executed.
  9. Next, assignment rules are run.
  10. Followed by the execution of auto-response rules.
  11. Salesforce runs Workflow rules and 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. Escalation rules are executed next.
  13. Salesforce  then executes the following 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. Next, entitlement rules are executed.
  15. Followed by, record-triggered flows that are configured to run after the record is saved.
  16. 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. 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.
  18. Salesforce then executes Criteria Based Sharing evaluation.
  19. Lastly, Commits are made to the database for all DML operations.
  20. After the changes are committed to the database, Salesforce executes post-commit logic such as sending email and executing enqueued asynchronous Apex jobs, including queueable jobs and future methods.

Conclusion

It is a standard best practices for a Salesforce administrator or developer to be aware of the order of execution of all automated processes on a single object to ensure that the insert, update or upsert of a record doesn’t cause unwanted issues or recursive operations.