The short version: you cannot order a flow against an Apex trigger at all, and you can only order flows against other flows on the same object with the same timing. What you can rely on is the documented save order — before-save flows, then before triggers, then validation. After triggers, then workflow rules, then after-save flows. Everything finer-grained than that is either unordered or ordered by a value that most orgs have never set.
What is actually deterministic
Three things, and they are enough to design with.
Timing slots are fixed. Before-save record-triggered flows run at step 3 of the save order, before all before triggers at step 4. After triggers run at step 8. After-save flows run at step 14, after assignment rules, auto-response rules, workflow rules and escalation rules. That ordering is documented and stable — you can build on it.
Flow trigger order works within its box. Every record-triggered flow can carry a trigger order value from 1 to 2,000, available since API version 54.0. Flows with values from 1 to 1,000 run first in ascending order. Flows with no value run next, in order of their created dates. Flows with values from 1,001 to 2,000 run last, ascending. Two flows with the same value fall back to alphabetical order by API name. All of that applies only to flows on the same object with the same before-save or after-save timing.
A nested save completes before the outer one continues. When a trigger or flow issues DML, that DML runs synchronously and its own save order finishes before the calling code moves to the next line. Nested, not queued.
What is not deterministic, and never becomes so
Flow against Apex. There is no ordering control between them beyond the timing slot they occupy. A trigger order of 1 does not make your flow run before an Apex before trigger — the flow was always going to run first, because before-save flows precede before triggers by definition.
Multiple Apex triggers on the same object. Explicitly documented as having no guaranteed order for the same event. Two before update triggers on Account will run in whatever order the platform chooses, and it can change.
Processes and workflow-launched flows. Step 13 of the save order runs Process Builder processes and flows launched by workflow rules “not in a guaranteed order,” in the documentation’s words.
Flows in managed packages. You cannot set a trigger order on somebody else’s flow. Ordering yours relative to a packaged flow is not something you control. You control only your own values, and the packaged flow lands wherever its own value, or lack of one, puts it.
Flows without trigger order values, over time. Created-date ordering is real but fragile as a design. Rebuild a flow in a new sandbox, deploy it fresh, and its created date changes, so does its position. Anyone relying on created-date order has an ordering dependency they did not write down.
Why interleaving Flow and Apex produces bugs that pass every test
Each component is correct. The interaction is not, and the interaction is what nobody tests.
The stale record problem
An after trigger cannot modify its own record in memory — Trigger.new is read-only after the save. To change a field it must issue an update, and that update runs a full nested save before the trigger’s next line. Later, at step 14, your after-save flow runs with the $Record values from the original save, which may no longer be what the database holds.
The flow then makes a decision on a stale value and writes something wrong. The Apex test passes because it asserts on the database after the whole transaction. The flow debugs correctly because the trigger is not doing anything in the debug run. Only the combination fails, and only sometimes, which is why these get logged as “intermittent.”
The double-count problem
A trigger increments a counter on the parent. An after-save flow on the same object also touches the parent, causing the child to be updated again by a roll-up path. Each write is once. The observable result is twice. In a recursive save, steps 9 to 17 are skipped, so the second pass behaves differently from the first. The automation that would have corrected the value does not run.
The invisible entry-condition problem
Your flow’s entry conditions are evaluated against the record at its timing slot. If an Apex trigger set the field the entry condition tests, the flow fires on records you never intended, or fails to fire on records you did. Nothing in either component’s definition mentions the other.
What to do about it
Reproduce with a log, not by reading the design. Setup → Debug Logs, add a trace flag for your user, set Apex Code to FINEST and Workflow to FINER, then reproduce the save. In the log, read the sequence of CODE_UNIT_STARTED and FLOW_START_INTERVIEW entries in order. Every DML_BEGIN between them is a nested save, and the entry immediately before it names what caused it.
Pick one mechanism per object per timing
This is the guidance that actually holds. Not “one flow per object,” which is unrealistic, and not “Apex only,” which strands your admins.
- One before-save owner per object. Either a before-save flow or a before trigger. If both exist, all same-record field derivation goes in one of them and the other stops touching fields.
- One after-save owner per object. Either after-save flows or an after trigger. Not both writing to the same records.
- Where you must have both, split by responsibility with no overlap: flow owns nothing that Apex reads, Apex owns nothing that flow reads. Write the split down in the flow’s description field and in a comment at the top of the trigger, because the next person will not infer it.
- Set trigger order values on every record-triggered flow, even when there is only one. Spacing them 10, 20, 30 leaves room to insert without renumbering, and it removes the created-date dependency.
The tradeoff is real: consolidating to one owner per timing means one artefact that more people need to change, and more merge contention. That is a better problem than an ordering bug you cannot reproduce.
Frequently asked
Does flow trigger order affect Apex triggers?
No. It only sorts record-triggered flows against each other, on the same object, with the same before-save or after-save timing. Apex position is fixed by the save order.
Can I make an Apex trigger run before a before-save flow?
No. Before-save flows are step 3 and before triggers are step 4. If your Apex must see the flow’s output, that already works. If the flow must see the Apex output, move that logic into the flow or into a before-save owner you control.
What order do after-save flows and after triggers run in?
After triggers first, at step 8. After-save flows at step 14, with assignment rules, auto-response rules, workflow rules and escalation rules in between.
Two flows have the same trigger order value. What happens?
They run in alphabetical order of their API names. It is deterministic but accidental. Renaming a flow silently changes the execution order, so do not rely on it.
Should I use a trigger framework to order Apex instead?
If you have more than one trigger per object, yes. Collapse them to one trigger that calls handlers in an order you control. That converts an undefined platform behaviour into a line of your own code, which is the whole point.
Do subflows inherit the parent’s position in the order?
Yes, in the sense that a subflow runs inline as part of the calling flow’s interview. It has no trigger order of its own and cannot be ordered independently.
Reference: Triggers and Order of Execution, Apex Developer Guide, and Flow, Metadata API Developer Guide, Salesforce. Trigger order value behaviour per “Guidelines for Defining the Run Order of Record-Triggered Flows,” Salesforce Help.
