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.
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.
Practice what you learned
1. Which of these runs first in the order of execution for a single record save?
2. What happens to validation rules when a workflow field update causes triggers to re-run on the same record?
3. What does Salesforce do if triggers and workflow field updates keep re-firing each other indefinitely?
4. Why might querying a roll-up summary field immediately after inserting detail records in the same transaction return a stale value?
5. At what point in the order of execution do assignment rules typically run?
Was this page helpful?
You May Also Like
Apex Triggers Basics
An introduction to what Apex triggers are, how their syntax and events work, and when to reach for a trigger instead of declarative automation.
Trigger Context Variables
A guide to Trigger.new, Trigger.old, their map equivalents, and the boolean context flags that let a single handler branch correctly across all seven trigger contexts.
Trigger Frameworks
Why orgs adopt a shared trigger handler framework, the core components such frameworks share, and how metadata-driven bypass mechanisms support safe data migrations.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics