Here's the thing you came for: a free Salesforce order-of-execution cheat sheet — the full save sequence in order, what runs in each phase, and the gotchas that actually bite. Download it, keep it next to your automations, and the rest of this post walks the sequence and why it explains half the "wait, why did that happen" moments in your org.
The single most useful thing to internalize about Salesforce automation is this: when you save a record, your automations do not run in the order you built them. They run in Salesforce's order. The flow you added last week can fire before the trigger you wrote three years ago. A validation rule can reject a value a before-trigger just set. A workflow field update can quietly run your trigger a second time. Almost every "why did that happen" moment traces back to this one fixed sequence — so it's worth knowing cold.
This is that sequence, verified against Salesforce's official Order of Execution documentation.
The order, every time you save
The record loads and system validation runs. Salesforce loads the existing record (or initializes a new one for insert), applies your new field values, and runs system-level validation — required fields, field types, maximum lengths.
Before-save flows run. Record-triggered flows set to run before the record is saved fire here — before any Apex trigger. This is the cheap place to set a field on the record being saved, because it needs no extra DML.
Before Apex triggers run. All
before insert/before updatetriggers.Validation rules and duplicate rules run. System validation runs again, then your custom validation rules, then duplicate rules. Note the position: this is after before-triggers — so a value a before-trigger set is still subject to validation.
The record saves to the database — but isn't committed. It's written inside the transaction, with an ID, but not yet permanent.
After Apex triggers run. All
after insert/after updatetriggers, now with the saved record and its ID available.Assignment, auto-response, and workflow rules run. Lead/case assignment, then auto-response, then workflow rules. Here's the classic gotcha: if a workflow rule does a field update, Salesforce updates the record again and re-fires your before-update and after-update triggers one more time (and only one more time). That single re-entry is behind a lot of "why did my trigger run twice" debugging.
Escalation rules run (cases).
After-save flows run — along with Process Builder and any process-launched flows. Because they run after workflow, they see the values workflow set. (Note: within this step, Process Builder and flows launched by workflow aren't ordered relative to each other.)
Entitlement rules run.
Roll-up summaries recalculate, then sharing is evaluated. Roll-up summary fields on the parent recalculate — and the grandparent, if there's a master-detail chain — which can send the parent record through its own save. Then criteria-based sharing is evaluated.
Everything commits. Only now is the DML permanent.
Post-commit work runs. Emails send, and asynchronous work — future methods, queueable jobs, async flow paths — is enqueued. This runs after commit, which is why failing the transaction can't take it back.
Two honest caveats the tidy list hides
The numbered sequence is real, but two things it can't show you matter just as much:
- Within a phase, order is not guaranteed. If two before-save flows both run, or three
after updatetriggers fire, Salesforce does not promise which goes first — you don't control trigger execution order, and record-triggered flow order isn't something you set with precision. Any diagram that confidently numbers the automations inside a phase is overstating what the platform guarantees. - This is the platform order, not your org's. The sequence is fixed. What's in each phase — which before-save flows, which triggers, which validation rules — is whatever you happen to have on that object. The doc gives you the skeleton; only your org has the actual automations.
The flow you added last week can fire before the trigger you wrote three years ago. Almost every "why did that happen" traces back to this one fixed sequence.
The honest catch — knowing the order isn't the same as knowing your org
Internalize the sequence above and you'll debug faster forever. But it only takes you halfway, and this is the honest boundary: the order is fixed, yet the only question you actually have on a bad afternoon is "what runs when I save an Opportunity in my org — in what order, touching what?" And that answer isn't in any doc. It's whichever before-save flows, before/after triggers, validation rules, and after-save flows you've accumulated, sorted into these phases — which you can only assemble by opening every automation on the object and placing it by hand.
That's exactly the tedium SchemaForce's Process Map removes. It reads the automations on an object and lays them out in this order-of-execution sequence for you — banded by phase, and deliberately not pretending to know the within-phase order Salesforce doesn't guarantee. You get your object's real save sequence at a glance, instead of reconstructing it from memory and forty Setup tabs. The platform order is yours to keep in your head; what automation removes is the part no one can hold there — your specific, drifting, real one.
Start here
Download the cheat sheet and keep it open the next time an automation does something you didn't expect — walk the phases in order and the culprit usually reveals itself (it's very often a workflow field update re-firing a trigger, or an after-save flow reading a value set earlier in the chain). Then, when you want the version that's specific to your org, that's what the Process Map is for. (Naming your flows so you can actually find the ones that touch an object is the unglamorous prerequisite — the Salesforce naming conventions standard covers that half, and its flow-naming rule is built for exactly this.)
