Order of execution in Salesforce

In this post we will review the order of execution in Salesforce when we save a record with an insert, update, or upsert statement. This is important to understand if you are an Salesforce Admin who works on automating processes or if you are a developer that writes trigger code. Both worlds will converge in the end and affect each other, so you have to bear in mind how Salesforce executes things internally.

What is Order of Execution in Salesforce?

Order of execution in Salesforce is a set of rules that describe the path a record takes through all automation and the events that happen from SAVE to COMMIT. Before Salesforce executes these events on the server, the browser runs JavaScript validation if the record contains any dependent pick-list fields. The validation limits each dependent pick list field to its available values. No other validation occurs on the client-side.

Check our old session on “Become an Order of Execution hero” to walk away with an understanding of how to design robust apps optimized for scale and how to control recursion and remedy typical problems.

Lots of person struggling to remember and visualize the order of execution which starts with a DML operation and there are involvements of triggers, different types of out-of-box automation’s like process builder, workflows, flows and different rules. I hope below diagram could be easy to understand and remember taking reference.

Order of Execution in Salesforce
Order of Execution.

Check latest version 56.0 here.

Order of Execution

Here is cheat-sheet of Order of execution. Salesforce performs the following events in below order.

  1. Loads Initial record.
  2. If the request came from a standard UI edit page, Salesforce runs system validation to check the record for page layout-specific rules, field definition, and Maximum field length.
  3. Executes before record-triggered flows.
  4. Executes all before triggers
  5. Runs most Custom validation.
  6. Executes duplicate rules
  7. Saves the record to the database, but doesn’t commit yet. 
  8. Executes all after triggers
  9. Assignment rules
  10. Executes auto-response rules
  11. Executes workflow rules. If there are workflow field updates,
    • updates the record again.
    • Due to Workflow field updates introducing new duplicate field values, executes duplicate rules again. 
    • If the record was updated with workflow field updates, fires before update triggers and after update trigger one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.
  12. Escalation rules.
  13. Executes these Salesforce Flow automations
    • Processes
    • Flows launched by processes
    • Flows launched by workflow rules (flow trigger workflow actions pilot)
  14. Executes record-triggered flows that are configured to run after the record is saved.
  15. Executes entitlement rules
  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. Executes Criteria Based Sharing evaluation
  19. Commits all DML operations to the database
  20. Executes all after-commit logic.
    • sending email.
    • asynchronous Apex jobs
    • Asynchronous paths in record-triggered flows

What is part of the after commit logic?

  1. All email sends
  2. Asynchronous Apex: @future methods
  3. Async Sharing Rule processing (for >25,000 records)
  4. Outbound Messages placed on queue
  5. Calculate Index, such as Search Index
  6. Render File Previews
  7. Publication of Platform Events (if configured)

Operations That Don’t Invoke Triggers

  • Cascading delete operations. Records that did not initiate a delete don’t cause trigger evaluation.
  • Cascading updates of child records that are reparented as a result of a merge operation
  • Mass campaign status changes, Mass division transfers, Mass address updates, Mass approval request transfers, Mass email actions
  • Modifying custom field data types
  • Renaming or replacing picklists
  • Managing price books
  • Changing a user’s default division with the transfer division option checked
  • Update account triggers don’t fire before or after a business account record type is changed to person account (or a person account record type is changed to business account.)
  • Update triggers don’t fire on FeedItem when the LikeCount counter increases.

Additional Considerations

The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event. For example, if you have two before insert triggers for Case, and a new Case record is inserted that fires the two triggers, the order in which these triggers fire isn’t guaranteed. Please implement Trigger framework for same.

Triggers and Order of Execution Video

Don’t forget to check below recording to learn about additional Considerations with some good example.

YouTube video

For interview questions on trigger, Check below link:

Salesforce Interview Questions on Triggers.


I hope this session helped you to understand the order of execution in Salesforce.

Amit Chaudhary
Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates.

He is a active blogger and founder of Apex Hours.

Articles: 466


  1. I wrote a before insert trigger and a custom validation on object. Checked the debug logs.
    Custom validation fires first and before insert does not fire when custom validation criteria is met. So is this diagram really correct?

    • This correct order is
      Loads Initial record.
      If the request came from a standard UI edit page, Salesforce runs system validation to check the record for page layout-specific rules, field definition, and Maximum field length.
      Executes before record-triggered flows.
      Executes all before triggers.
      Runs most Custom validation.
      Executes duplicate rules.
      Saves the record to the database, but doesn’t commit yet.
      Executes all after triggers.

  2. I think first before trigger gets fired and performs its operation but in custom validation steps the criteria of validation is fulfilling so you are getting an error.

  3. Could you please give the details for demo process? I don’t know how can I try the demo on my local. Thank you so much!

      • Both of them that shown in the vedio. I want to try to do the Demos in the video myself to better understand the principles. I think your example is the most illustrative of the problem. Among all the videos I watched, you gave the best explanation.

      • Hi @Amit Chaudhary, I have another question:
        When we should conside order of execution? Or Under what circumstances or scenarios do we need to consider this function? Most of time the salesforce system designer conside and resolve it, right?

Leave a Reply

Your email address will not be published. Required fields are marked *