Learn Salesforce Order of Execution [Infographic]

Share this article...

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 yet: 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. This article reviews:

  1. Reference diagram with detailed steps
  2. Full list of from the Developer Docs
  3. Key considerations from Order of Execution and Flow Behavior before and after Spring ’22

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 v54

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 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. 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 updates 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 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 are executed.
    • 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 and Changes from Flow Behavior

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, 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 & 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 causes 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 & 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.
    • Flows of the same type runs in the order specified in the flow:
      • Runs flows ordered 1-1000 first
      • Then unordered flows
      • Then flows ordered 1001-2000
    • API 54 Changes to Flows:
      • 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.
  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 BAs, Admins, Developers, Testers, and Architects!

27 thoughts on “Learn Salesforce Order of Execution [Infographic]

  1. No. Process builder also gets back to the before trigger, so we can have even three before triggers.

  2. This is great! I wish this diagram highlighted the “Save” and “Commit” steps in another color for reference, like a landmark.

    1. What events in the save order of execution could cause a New DML event?
      Apex triggers?
      System validation rules?
      Custom validation rules?
      Duplicate rules?
      Calculations for roll-up summary fields?
      Cross object workflows?
      Evaluation of criteria-based sharing?

  3. 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: https://developer.salesforce.com/docs/atlas.en-us.232.0.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) seems to suggest your Infograph is correct.
    I think the difference need to be addressed, otherwise the public will be confused.

  4. 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.

  5. 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—-


    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.


    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?


    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”.

  6. 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.

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

Add Comment