Admins / Developers / Platform

Salesforce Order of Execution Simplified + Infographic

By Marlene Reeve

Building solutions with Salesforce is a fairly easy task, but if you do not go below the surface, your solutions may end up creating unintended technical debt in your system. This can slow down your org, or worse – you may start finding fatal errors due to exceeding limits.

When you save a record, it goes through a specific sequence of events which is the Salesforce Order of Execution.

In this article, we will take a look at:

  1. Reference diagram with detailed steps
  2. Full list from the developer docs
  3. Key considerations from Order of Execution and Flow behavior before and after Spring ’22 release

Salesforce Order of Execution

Declarative, low code, and code solutions are all woven into the Order of Execution and affect how your system runs. Whether you are an admin, developer, or architect, always keep in mind how your new solution is affecting and interacting with the existing org standard functionality, managed packages, and existing customizations.

Order of Execution from Developer Docs API v60

The following are the steps that occur on the server when you save a record. Don’t worry, you do not need to memorize the list! Instead, use the diagram above for reference.

  1. Load the original record from the database or initialize the record for an upsert statement.
  2. Load the new record field values from the request and overwrite 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, it verifies that any custom foreign keys don’t 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. Execute record-triggered flows that are configured to run before the record is saved.
  4. Execute all before triggers.
  5. Run most system validation steps again, such as verifying that all required fields have a non-null value and run 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. Execute 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.
  7. Save the record to the database but don’t commit just yet.
  8. Execute all after triggers.
  9. Execute assignment rules.
  10. Execute auto-response rules.
  11. Execute workflow rules. If there are workflow field updates:
    • Update the record again.
    • Run system validations again. Custom validation rules, flows, duplicate rules, processes, and escalation rules aren’t run again.
    • Execute before update triggers and after update triggers, regardless of the record operation (insert or update), one more time (and only one more time).
  12. Execute escalation rules.
  13. Execute 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. Execute record-triggered flows that are configured to run after the record is saved.
  15. Execute entitlement rules.
  16. 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 a 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, perform calculations and update the roll-up summary field in the grandparent record. Grandparent record then goes through the save procedure.
  18. Execute criteria-based sharing evaluation.
  19. Commit all DML operations to the database.
  20. After the changes are committed to the database, execute post-commit logic.
    • Examples of post-commit logic (in no particular order) include:
      • Sending an email
      • Enqueued asynchronous Apex jobs, including queueable jobs and future methods
      • Asynchronous paths in record-triggered flows

Important Considerations for Order of Execution and Changes from Flow Behavior Before and After Spring ‘22 Release

In recent releases, the biggest change to the Order of Execution in Salesforce has been the introduction of flows. These are the important considerations and changes announced in the Spring ’22 release.

1. Validation

  • System validation checks for values in required fields, field type and length validation, etc.
  • If the record is updated in the UI, system validation includes page layout-specific settings for Edit/Read only fields.
  • All active validation rules are evaluated for all record saves.
  • Custom validation rules and dup rules only run one time.

2. After Triggers, Assignment, and Auto-Response Rules Execute

  • Records are further updated per the custom code logic.
  • Assignment rules update the record owner per the first rule that matches your record.
  • Assignment rules run on creation or if they are called via apex to be rerun on record updates.
  • Auto-response rules run on record creation and prepare the email to be sent per the first rule that matches your record.
  • If you have multiple triggers per object, you cannot set the order in which they fire.

3. Workflow Rules, Approval Processes, and Process Builders Run – Potential Loop Time!

  • All active workflow rules are evaluated for all record saves.
  • Approvals are treated as workflows.
  • For workflow rules, field updates are executed before all other actions.
  • All active Process Builders are evaluated for all record saves.
  • For all field updates that cause re-evaluation, all WFR/AP/PB that did not run one time are re-evaluated up to 5 additional times.
  • Each workflow rule and Process Builder field updates records causing system validation, before triggers, and after triggers to run for each cycle.
  • Like triggers, for WFR/AP/PBs, you cannot set the order in which they run.

4. Before Save and After Save Flows

  • Before-save flows are run right after system validation.
  • Flows are executed only one time per entity, per transaction.
  • Only flows with matching entry criteria run for record saves.
  • Set running order for the same object.
  • Time-based field updates are a separate transaction and run flows only.
  • Run before Entitlement Rules, so that entitlements can include the record updates that after-safe flows make.
  • Flows of the same type run in the order specified in the Flow:
    • Run flows ordered 1-1000 first
    • Then, unordered flows
    • Then, flows ordered 1001-2000

5. Omni Routing

  • When work is routed and assigned, triggers, workflow rules, approval processes, and escalation rules do not run.
  • Once the record is edited and saved again, the standard operations run.


In most orgs, you will end up with clicks with code, so use the Salesforce Order of Execution to your advantage. Maximize the success of your solutions and your system with these key takeaways:

  • The Order of Execution affects every saved record on the UI or via API.
  • The order may be different based on the API of your components.
  • Stay up to date with each release to see any changes made.

Share this information with your full Salesforce team, including business analysts, admins, developers, testers, and architects!

The Author

Marlene Reeve

Salesforce Solutions Architect | 10X Salesforce Certified | 4X Trailhead Ranger


    Stephanie Boggs
    January 18, 2021 1:37 pm
    This is the best, most detailed explanation/list I've seen! Bookmarking!! Thank you!
    Salesforce Automation
    January 21, 2021 9:53 am
    Salesforce really turn to be hero..
    Alan Ruan
    January 27, 2021 6:07 am
    How about the before-save flow?
    Laurie Hanlon
    February 15, 2021 4:25 pm
    Pretty sure that was #3 "Executes flows that make a “before-save” update (new change in Winter 20)."
    May 02, 2021 9:04 pm
    No. Process builder also gets back to the before trigger, so we can have even three before triggers.
    October 18, 2021 10:22 pm
    This is great! I wish this diagram highlighted the "Save" and "Commit" steps in another color for reference, like a landmark.
    Gunjan Mistry
    November 13, 2021 7:22 am
    This is the best way to explain the order of execution. Thank you very much!
    Teck Lung Ng
    February 19, 2022 5:09 am
    Your infograph shows ESCALATION RULES comes before PROCESSES AND FLOW. Your article itself tells us that Step 13 - Executes processes and flow, and then Step 14 - Escalation rules. So which one should execute before which one? The official "Triggers and Order of Execution" (Source: seems to suggest your Infograph is correct. I think the difference need to be addressed, otherwise the public will be confused.
    Christine Marshall
    February 21, 2022 9:52 am
    Thanks for letting us know about this typo. It has now been corrected!
    Tom S
    February 23, 2022 7:28 pm
    suggest you merge 11 and 12 descriptions so the description match the image, or you could update the image.
    Christine Marshall
    February 24, 2022 10:19 am
    Great idea Tom! I've done that.
    Mehdi Maujood
    March 17, 2022 4:03 pm
    Spring 22 update: The order of points 14 and 15 has changed:
    Christine Marshall
    March 18, 2022 10:38 am
    The order is Entitlements then Record Triggered Flows which is the same as our guide/image?
    Katharine Miller
    March 20, 2022 8:59 pm
    As of v54, it's the other way around: Record-triggered Flows first, then Entitlement rules: (the link posted above was for v52)
    April 18, 2022 4:04 am
    Which flows are executed at #13?
    April 18, 2022 12:44 pm
    They have swapped entitlements and after triggered flows indeed. v54.0 14. Executes record-triggered flows that are configured to run after the record is saved. 15. Executes entitlement rules.
    Neil Banerjee
    May 02, 2022 4:15 pm
    This is great! Very clear in explaining all the additional scenarios.
    Dinesh Yadav
    May 02, 2022 9:15 pm
    Very informative article! Thank you Marlene!
    May 04, 2022 10:04 am
    This is great - concise and very clear!
    May 04, 2022 11:53 am
    This is great. Much easier is to follow such a diagram than read through a block of text. Please add the "Last updated" date on the picture or version number. Something that can be referenced to check if my local copy is outdated as I see some suggestions for changes above.
    Mat Kennedy
    May 04, 2022 10:26 pm
    This is really thorough and here is a song (Salesforce Order of Execution) to help remember all of the steps
    May 19, 2022 9:03 am
    What events in the save order of execution could cause a New DML event? Apex triggers? System validation rules? Custom validation rules? Duplicate rules? Workflows? Processes? Flows? Calculations for roll-up summary fields? Cross object workflows? Evaluation of criteria-based sharing?
    August 23, 2022 11:46 pm
    Too funny. How do I get in touch with this Andrew Hart fella? :)
    November 07, 2022 11:08 pm
    Any update to this after Winter '23 release?
    andrew ermon
    November 15, 2022 5:19 pm
    Like everyone else said, this is phenomenal, and any serious Salesforce declarative developer should have this saved in their favorites. ---Want to call out a niche but probably not uncommon use-case that I discovered recently involving OOE---- CONTEXT: There is a screen flow that is launched when the user clicks a button on the Account record detail page. 1. The user inputs a text response in the screen element and clicks "submit", 2. The flow then updates a User lookup field on the Account record that launched the flow. 3. The flow then has a Action element that launches an Approval Process. ...end of flow... The Approval Process launched by the screen flow uses the value in the Account record's User lookup field to determine who to send the approval request to. QUESTION: Since the Approval Process is launched in an action within the same flow as the record update... Does the Approval Process use the current or updated User lookup field value to determine who to send the approval request to? Which is really a question of OOE - does the screen flow record update action get saved to the database before the Approval Process logic runs, or after? ANSWER: The Approval Process will run AFTER the FLOW transaction/interview finishes. "At run time, the approval request isn’t created until the interview’s transaction is completed. Transactions are complete when the interview either finishes or executes a Screen, Local Action, or Pause element." From Salesforce help article "Flow Core Action: Submit for Approval".
    andrew ermon
    November 16, 2022 6:36 pm
    Question because I couldn't find an answer to this anywhere else: How do CRUD actions within a screen flow get executed? From the debugger and from testing it out in real life, it appears as though any record action elements (CRUD) BEFORE a screen element get executed and committed to the database, and then any elements AFTER a screen element get executed and committed in a different transaction. The problem this creates is if you have another after-save record triggered flow for the same object that the screen flow performs CRUD action on. Since there are two record update transactions that occur within the same screen flow, an after-save record triggered flow would potentially be triggered TWICE (assuming the entry criteria were met). This happened to me in real life. I had a screen flow that had a record Updated element and also a Action element to launch an Approval Process. I thought, looking at the OOE documentation, that the transactions would go in the following order: 1. Screen flow actions/CRUD committed 2. Approval Process launched (from screen flow action element) 3. Approval Process transaction completed 4. After-save record triggered flow runs Instead, the record update in the screen flow causes the After-save record triggered flow to fire BEFORE the Approval Process. I know this because when I test it, the screen flow errors out and the After-save flow is listed as the reason why. The Approval Process has a record update action that makes the record NOT meet the After-save flow entry criteria, so if the AP was executed before the After-save flow, the after-save flow would not be getting triggered and would not be erroring out.
    Amit R
    December 09, 2022 5:21 pm
    I found this article very useful, especially after a call with SF support in solving a performance issue. I do think we should also add what really happens in SF. I was told that there are different threads that execute for "workflow field update", so if there are 100 records in DML, the 100 java-threads will be executed as workflow field updates are not bulkified. i do not know if same things are true for running the triggers. each trigger getting executed in some order is understood, but whether each trigger runs in its own thread or not is good input. Also, when rollup happens - is there soql query done to retrive children records - considering the records may be getting modified concurrently - etc.
    RR Jennings
    June 16, 2023 3:00 pm
    Is there an available link to a one-page printable version of the infographic?
    Carlos Cruz
    May 15, 2024 9:18 pm
    Thanks for the update and simplification. A must-have bookmark.

Leave a Reply