Salesforce Order of Execution, Step by Step

By Prit Sakhvala, Salesforce Developer · Updated July 2026

The full sequence for a record save

1. Load / initialize. The original record is loaded (or initialized for insert) and new field values are overwritten onto it.
2. System validation. Required fields, field formats, maximum lengths, foreign keys. (For UI saves, layout-level rules run too.)
3. Before-save record-triggered flows. Fast same-record updates, no extra save needed.
4. Before triggers (before insert/update/delete).
5. System validation again + custom validation rules. Your validation rules run after before triggers — so a before trigger can fix data that would otherwise fail validation.
6. Duplicate rules. A blocking duplicate rule aborts the save here.
7. Record saved to the database — but not committed. IDs exist now; nothing is permanent yet.
8. After triggers (after insert/update/...).
9. Assignment rules (Leads/Cases), then auto-response rules.
10. Workflow rules. ⚠️ If a workflow field update changes the record, before and after update triggers fire one more time (only once more — not infinitely).
11. Escalation rules (Cases).
12. After-save record-triggered flows (and legacy processes). Updates to the same record here re-enter the save sequence.
13. Entitlement rules.
14. Roll-up summaries & cross-object formulas. Parent (and grandparent) records recalculate and save — running their triggers.
15. Criteria-based sharing evaluation.
16. Commit. Everything above succeeds or the whole transaction rolls back.
17. Post-commit logic. Emails send, and queued async work (future methods, queueables) is enqueued to run in separate transactions.

This is the standard sequence as documented in the official Salesforce order-of-execution reference — worth bookmarking, since Salesforce occasionally adjusts details between releases.

The consequences that bite people

• "My validation rule didn't catch it" — because a workflow field update or after-save flow changed the value after validation ran.
• "My trigger ran twice" — workflow field updates and same-record after-save flow updates legitimately re-fire update triggers. If your trigger isn't idempotent, you get doubled logic.
• "The rollup didn't see my change" — order matters: roll-ups recalculate near the end; logic that reads parent totals in an after trigger sees pre-recalc values.
• "The email sent but the record failed" — it can't: emails go post-commit. But async jobs enqueued during the transaction die with a rollback.
• Recursion cascades — trigger updates parent → parent trigger updates children → repeat. Each hop re-spends governor limits and CPU.

Seeing the real order in your own org

The list above is the theory. Your org's reality — which of your flows, triggers and rules ran, in which order, for a specific save — is written in the debug log as a sequence of CODE_UNIT_STARTED, FLOW_START_INTERVIEW, VALIDATION_RULE and WF_RULE_* events. Reading that interleaving by hand works (see how to read Apex debug logs) but is slow.

This is ForceLens's signature feature: its Order of Execution view reconstructs the diagram from your actual log — every trigger, flow, validation and workflow in the order they really fired, including re-entries. The whiteboard drawing, generated from production truth.

Frequently asked questions