Salesforce order of execution, explained

The Salesforce save order, step by step

For a single record on insert or update, Salesforce executes roughly this documented sequence. (Salesforce revises the list over time; this reflects the current order including before-save record-triggered flows.)

1. Loads the original record from the database, or initializes it for an upsert.
2. Loads the new field values from the request and overwrites the old ones. If the request came from a standard UI edit page, runs layout-level system validation (required fields, field formats, maximum length).
3. Executes record-triggered flows configured to run before the record is saved (before-save flows).
4. Executes all before triggers (Apex).
5. Runs system validation again (required fields have non-null values, correct formats) and all custom validation rules.
6. Executes duplicate rules; if a rule blocks, the save is rejected here.
7. Saves the record to the database - but does not commit yet.
8. Executes all after triggers (Apex).
9. Executes assignment rules, then auto-response rules.
10. Executes workflow rules. If a workflow field update fires, the record is updated again and its before/after update triggers plus standard validation run one more time (but not custom validation, duplicate, or escalation rules).
11. Executes escalation rules.
12. Executes record-triggered flows configured to run after the record is saved (after-save flows), and processes launched by Process Builder.
13. Executes entitlement rules.
14. If the record has a roll-up summary field or is in a cross-object workflow, recalculates it and runs the parent (and grandparent) through their own save procedure.
15. Runs criteria-based sharing evaluation.
16. Commits all DML to the database.
17. Runs post-commit logic: sending email, and everything enqueued to run asynchronously - @future methods, Queueable and Batch jobs, and the asynchronous paths of record-triggered flows.

Where each automation type fires

The single most useful thing to internalize is which tool runs when:

• Before-save flows & before triggers — set field values on the record being saved without a second DML. Cheapest place to default or normalize a value.
• Validation rules — fire after before-logic, so they judge the record as your before-automation left it, not what the user typed.
• After triggers — the record now has an ID; use them for related-record work and cross-object logic.
• Workflow field updates — run after save and re-enter update triggers; a classic source of double-firing.
• After-save flows — run late; ordering against each other is not guaranteed without Flow Trigger Order.
• Roll-ups & async — parent recalculation happens before commit; @future/Queueable run only after commit, so their writes are a separate transaction.

Flows vs triggers vs workflow: what runs first

For the same object on the same save: a before-save flow runs before a before-trigger; a before-trigger runs before validation; an after-save flow runs after an after-trigger; and workflow field updates run after both, re-firing update triggers. So when two automations disagree about a field's value, the winner is whichever runs last in this sequence - not whichever was "supposed" to own it. That is why "it worked in the sandbox" so often hides an ordering assumption.

Classic order-of-execution bugs

• Overwritten values. A before-save flow sets a field, then a before-trigger (or later workflow update) sets it again. Last writer wins.
• Recursion. An after-trigger updates the same record and re-enters the save order, firing triggers again - governor-limit territory without a re-entry guard.
• Validation vs before-logic. A validation rule rejects a value your before-automation just computed, because validation runs after before-logic.
• Non-deterministic flow order. Two active after-save flows write the same field with no Flow Trigger Order set, so the result depends on undefined ordering.
• Workflow re-entry. A workflow field update silently re-runs update triggers and standard validation a second time on the same save.

See your own org's real automation order (offline)

The documented order tells you the phases; it does not tell you which of your automations occupy each phase on a given object. sf-intelligence answers that from a read-only metadata snapshot - no deploy, no live call:

• sfi.order_of_execution — the save-order phases populated with your org's actual triggers, flows, validation, and workflow for an object.
• sfi.what_happens_on_save — a plain-language walkthrough of everything that fires when a record on that object is saved.
• sfi.automation_collisions — flags where multiple automations write the same field or share a trigger phase with undefined order - the structural risks above, surfaced before they bite.
• sfi.explain_flow — what a specific record-triggered flow actually does, its trigger, and the fields it writes.

FAQ