Here's the thing you came for: the order that flows, Apex triggers, and validation rules fire in when a record is saved — because that order is what decides which one wins. The cheat sheet below has the full sequence; this post is the part people actually trip on, which is the handful of steps around the save itself.
Three kinds of automation can touch a record on save — a flow, an Apex trigger, and a validation rule — and the single question that causes the most confusion is simply which one goes first. The answer isn't "the one you built first" or "it depends." It's fixed, and here's the part that matters:
The order, around the save
For a record being saved, the relevant slice of Salesforce's order of execution is:
- Before-save flow — runs first, before any Apex.
- Before Apex trigger —
before insert/before update. - Validation rules (then duplicate rules).
- The save to the database.
- After Apex trigger —
after insert/after update. - …then assignment, auto-response, and workflow rules…
- After-save flow — which is why it can see values workflow set.
Read that top to bottom and the common "why did that happen" answers fall out:
- Your before-save flow runs before your before-trigger. If both set the same field, the trigger wins, because it runs later and overwrites. If you expected the flow's value to stick, this is why it didn't.
- A validation rule can reject a value your flow or before-trigger just set. Validation runs at step 3 — after the before-logic. So "my automation sets this field, but I get a validation error" is not a contradiction; the rule is validating exactly what your automation produced.
- An after-save flow sees more than a before-save flow. It runs at step 7, after triggers and workflow, so it has the record's ID and the results of everything upstream. That's the right place for "create a related record" logic — and the wrong place to cheaply set a field on the record itself.
So which should you use?
- Before-save flow — to set fields on the record being saved. It's the cheapest option (no extra DML, no code) and Salesforce's own guidance is to prefer it over a before-trigger for simple field updates. Reach here first.
- Before Apex trigger — when the logic is genuinely beyond a flow: complex bulk processing, callouts' prep, things declarative tools can't express. Runs just after the before-save flow.
- Validation rule — to enforce integrity. Because it runs after the setters, it validates near-final values — which is usually what you want, but means it can catch values your own automation created.
- After-save flow — for related records and anything needing the saved record's ID.
The honest caveat
Two of these steps hide something the tidy list can't show. Within a single step, order isn't guaranteed: if two before-save flows run, or three after-update triggers fire, Salesforce doesn't promise which goes first. You control the phase, not the order inside it — so the fix for "these two automations fight" is usually to consolidate them, not to try to sequence them. (The full order of execution covers the whole sequence and this caveat in depth.)
The honest catch — this is the generic order, not your org's
Knowing the sequence is half of it. The other half is knowing what's actually on your object: which before-save flows, which triggers, which validation rules you've accumulated, and where each one lands in this order. That list isn't in any doc — it's whatever your org happens to have, and reconstructing it means opening every automation on the object and placing it by hand.
That's what SchemaForce's Process Map does for you: it reads an object's automations and lays them out in this exact order-of-execution sequence, banded by phase — honestly not pretending to know the within-phase order Salesforce doesn't guarantee. The order above is yours to memorize; what the tool removes is assembling your object's real one from memory and forty Setup tabs.
