Pick one automation tool per object and use it for everything on that object. Not because mixing tools is forbidden, but because the execution order between a trigger and a flow on the same object is not something you can reason about from the builders, and every debugging session on a mixed object starts by rediscovering that. Break the rule deliberately, in the three cases below, and write down why.
The actual problem is ordering, not tooling
Salesforce publishes the order of execution: before-save flows, then before triggers, then validation rules, then the save, then after triggers, then after-save flows, then roll-ups. That much is fixed and knowable.
What is not knowable is the order within a category. Two after-save flows on the same object run in an order you cannot set from the builder and should not depend on. Two triggers on the same object have the same problem. Once you have a trigger writing a field and a flow reading it, you have a system whose behaviour depends on an ordering nobody chose.
One tool per object does not fix ordering. It makes ordering expressible: inside one trigger handler or one flow, you control the sequence explicitly.
Which tool to pick
| Choose Flow when | Choose Apex when |
|---|---|
| Admins will maintain it | Logic needs Maps, Sets or sorting |
| Logic is field updates and record creation | You need partial-success DML |
| Criteria are simple and stable | You need savepoints or explicit rollback |
| Volume per transaction is modest | Callouts are involved |
| Change frequency is high | The object is high-volume and CPU matters |
My default for a new object is Flow, and I change my mind when the first requirement arrives that Flow handles awkwardly. The reason is not that Flow is better — it is that the population who can maintain a flow is much larger than the population who can maintain a trigger, and most automation outlives the person who wrote it.
The counter-case is honest too: past a certain complexity a flow becomes a worse artefact than the equivalent Apex, because it cannot be diffed usefully, cannot be unit-tested to the same standard, and cannot be read in one screen. If you are building decision trees five levels deep in Flow, the tool has stopped helping.
The three times to break it
1. Before-save field updates on a high-volume object
A before-save flow that sets a field on the record being saved is the cheapest automation on the platform — no extra DML, no re-entry. If the object’s main automation is a trigger, adding one before-save flow for simple field defaults is still usually the right call, because the alternative costs CPU in the trigger for no benefit.
Condition: the flow must only write to $Record. The moment it writes to another object, it is not a field update any more and the exception does not apply.
2. A managed package already owns the object
You cannot consolidate into a package’s trigger. So on a packaged object you are always mixing, and the rule becomes: keep your automation in one tool, and treat the package’s behaviour as part of the environment. Read the LIMIT_USAGE_FOR_NS lines in a FINEST debug log to see how the transaction’s budget is actually split before you assume the slowness is yours.
3. A screen flow that also happens to write records
Screen flows are a user interface, not object automation. A screen flow updating Accounts does not violate one-tool-per-object in any meaningful sense, because it is not competing for the save path. Counting it as a violation leads people to strange conclusions.
Consolidating an object that already mixes
This is a rewrite of working automation with no test suite proving equivalence, so do it in stages and be honest about the risk.
- Inventory. Every trigger, flow, process builder and workflow rule on the object, with its trigger type and criteria.
- Map every write. For each, which fields on which objects it writes. This is the document that survives. The rest is commentary.
- Find the overlaps. Two automations writing the same field is where the ordering dependency lives, and it is where the behaviour change will happen.
- Move one at a time, with the old one deactivated rather than deleted. Reactivating is your rollback.
- Compare limit usage before and after on the same save, using a FINEST log. If it went up, you have consolidated the structure and not the cost.
Do not consolidate an object nobody is complaining about. The value is in transactions that are slow, ordering-dependent, or failing. A tidy object with three independent flows and no interaction between them is not costing you anything.
What one tool per object does not solve
It does not reduce the number of objects a save writes to, which is usually the real cost — see dependency sprawl. It does not prevent re-entrance. And it does not make a flow with forty elements comprehensible.
It is a rule about where logic lives, and the benefit is that a person debugging in eighteen months has one place to look. That is a real benefit and a modest one, and overselling it is how it turns into a dogma that gets applied to objects where it costs more than it returns.
Frequently asked
Can I control the order of two flows on the same object?
Flow Trigger Order lets you assign a priority value to record-triggered flows on an object, which does give you influence over sequence within the same trigger type. It is still weaker than sequencing inside one artefact, and it is one more thing to discover during an incident.
Does a trigger always beat a flow on performance?
Not always, and the difference is usually smaller than the number of automations. A before-save flow is cheaper than an equivalent after-save trigger. Measure with a debug log rather than assuming.
What about Workflow Rules and Process Builder?
Both are retired for new development and should be migrated. If you still have them, migrating them is the consolidation. Do not build a one-tool-per-object plan around keeping them.
Is it one tool per object or one automation per object?
One tool. Several record-triggered flows on an object are fine if they do not interact. The rule is about not mixing Apex and Flow on the same save path.
How do I convince a team that has always mixed?
Do not argue in the abstract. Take the slowest save in the org, produce the FINEST log, and show the list of code units that ran. The argument makes itself.
Reference: Triggers and Order of Execution, Salesforce Apex Developer Guide; Flow Trigger Order and Migrate to Flow, Salesforce Help.
