The Order of Execution

Analogy categoryAnalogies

What Is the Order of Execution?

The order of execution is the precise, fixed sequence of steps Salesforce runs every time a record is saved, covering system validation, Apex triggers, validation rules, and automation like flows and assignment rules, and it is not something a developer can reorder. Understanding this sequence matters because it explains behaviors that otherwise look like bugs, such as a before-trigger's field update showing up in a validation rule's evaluation, or a workflow field update on the same save causing a trigger to run a second time.

🏏

Cricket analogy: The fixed order of execution is like the mandatory sequence of a Test match day, toss then playing-conditions check then the first session, which no captain can reorder no matter how much they'd prefer to bat first without the toss.

The Save Order, Step by Step

For a single-record save, Salesforce first runs system validation such as required field and data type checks, then executes any before triggers on the object, then runs most custom validation rules alongside duplicate rules, then executes after triggers, and only after the record is committed does it evaluate assignment rules, auto-response rules, workflow rules, and processes/flows, with any workflow field updates on the same record causing before and after triggers to run again in a second, more limited pass before the record is finally, permanently saved and commits are made available to other transactions.

🏏

Cricket analogy: Stepping through the fixed save sequence is like an innings breaking down into overs, each over having six deliveries in a strict order, where the third ball of an over can't happen before the second no matter what.

text

1. System validation (required fields, data types, field-level security)
2. Before triggers (before insert / before update / before delete)
3. Most custom validation rules run
4. Duplicate rules run
5. Record is saved to the database, but not yet committed
6. After triggers (after insert / after update / after delete / after undelete)
7. Assignment rules
8. Auto-response rules
9. Workflow rules (field updates here re-run steps 2 and 6 once, but NOT step 3)
10. Escalation rules, entitlement rules
11. Record is committed; roll-up summary fields on the parent recalculate
12. Post-commit logic runs: emails, DML on other rows from triggers, etc.

Workflow Field Updates and Trigger Re-Entry

When a workflow rule (or a record-triggered flow's immediate field update) modifies a field on the same record being saved, Salesforce re-runs the before and after triggers on that record a second time to reflect the new field value, but critically does not re-run validation rules during that second pass, which is why validation rules cannot catch bad data introduced by a workflow field update. This re-entry happens only once per save for workflow-driven updates - Salesforce enforces a limit to prevent infinite loops, and exceeding it throws a runtime error about too many workflow actions.

🏏

Cricket analogy: A workflow field update causing triggers to re-run is like a third umpire's review overturning a decision, forcing the scorecard and the bowler's figures to be recalculated a second time to reflect the new outcome, but the toss itself is never redone.

If a workflow rule's field update and an after-update trigger's own DML modify the same record in ways that trigger each other repeatedly, Salesforce will eventually throw a maximum recursion depth error rather than looping forever - but relying on hitting that limit as your error-handling strategy means the transaction still fails, so recursive re-entry should be designed out proactively with recursion guards.

Why This Matters for Rollups and Cross-Object Automation

Because after triggers on the parent object run before assignment rules, workflow rules, and most flow automation, any child records your after-insert trigger creates already exist by the time later automation like assignment rules runs, but roll-up summary fields on a master-detail relationship recalculate as part of the same save transaction whenever a detail record changes, which is why a trigger creating detail records in the same transaction as the parent's insert can see stale rollup values if it queries the parent immediately afterward rather than recalculating in Apex. Developers building cross-object automation must trace exactly which phase their logic runs in to avoid reading fields, like a roll-up summary, before Salesforce has actually recalculated them.

🏏

Cricket analogy: Querying a stale rollup mid-transaction is like checking a team's net run rate on the table the instant a match ends, before the scorers have finished recalculating it, showing you yesterday's number instead of the just-completed match's impact.

A common real-world pitfall: an after-insert trigger on OpportunityLineItem creates records, then immediately queries the parent Opportunity's roll-up summary Amount field expecting it to reflect the new line item - but because the rollup recalculation and the trigger's own query happen within the same save transaction, the freshly queried value may still be stale, so developers often recalculate the total manually in Apex rather than relying on re-querying the rollup mid-transaction.

The order of execution is a fixed, non-reorderable sequence Salesforce follows for every DML save.
System validation and before triggers run first, followed by most validation rules and duplicate rules, then after triggers, then the record commits.
Assignment rules, auto-response rules, workflow rules, and most flow automation run only after the record has already been saved once.
A workflow field update on the same record causes before and after triggers to re-run once, but validation rules do NOT re-run in that pass.
Salesforce caps workflow-driven recursion depth and throws an error rather than looping forever if triggers and workflow updates keep re-firing each other.
Roll-up summary fields recalculate within the same save transaction, so querying them immediately after creating detail records can return stale values.
Tracing exactly which phase your automation runs in is essential to avoid reading fields before Salesforce has actually recalculated them.