For most of the last decade the default instinct in a Salesforce org was simple: if a requirement carried any complexity, you opened your development environment and wrote Apex. Flow was for administrators who wanted to feel useful. That view is now badly out of date, and the teams still holding it spend weeks rewriting working automation on the strength of a habit rather than a reason.
Flow in 2026 is a different product from the one many engineers remember. Element execution is faster, bulk handling is automatic for most patterns, the trigger ordering between Apex and Flow is well defined, and source-tracked deployment through the metadata API has matured. The question is no longer Flow versus Apex on principle. It is Flow versus Apex against a small set of criteria you can name out loud, and that is what this piece is about.
01 / CONTEXTWhat actually changed
Three shifts between 2022 and now reset the decision. Flow performance improved to the point where it is comparable to Apex on small and medium workloads. Invocable Apex matured, so you can drop a single Apex method into an otherwise declarative Flow without abandoning the rest of the declarative experience, which means a mixed solution is no longer a design smell. And the change-management story improved, with proper version control, source tracking, and git-based deployment finally within reach for Flow.
So the old guidance, Apex by default and Flow only for trivia, is simply wrong now. The useful question is where each tool genuinely wins.
02 / FLOWWhere it shines now
Reach for Flow when the logic is mostly conditional branching on field values, when volume stays under a few thousand records per transaction, when the owner of the logic will be an administrator rather than a developer, when you expect the rules to change every quarter as the business evolves, and when most of the work is calling other Salesforce features such as email alerts, record updates, approvals, and screens.
Concretely, that covers lead routing, case escalation, opportunity stage automation, simple approval orchestration, screen-based intake forms, and the preparation steps ahead of quote generation. This is a large share of the automation in a typical org, and Flow now owns it cleanly.
Flow has earned the default seat at the table. The question is no longer whether to use it, but where to stop.
03 / APEXWhere it still wins
Choose Apex when the logic involves complex transformations across many objects, when you need genuine exception handling, savepoints, or fine-grained rollback control, when volume regularly exceeds ten thousand records per transaction, when the logic must be callable from systems outside Salesforce, when you need recursion, dynamic SOQL, or the Schema namespace, and when an integration requires asynchronous queueing or scheduled jobs.
Concretely, that is anything touching finance such as revenue recognition or billing reconciliation, anything invoked from a public API, and anything where a partial failure must roll cleanly back to a savepoint. These are the places where Apex is not a preference but a requirement.
04 / MATRIXThe picture we draw on the whiteboard
When we sit with a client and a marker, the conversation resolves to a two-by-two of logic complexity against transaction volume. Most orgs need both tools, in different quadrants, and the argument about which is morally superior evaporates once the axes are drawn.
05 / TRAPThe bulkification mistake
A common failure: a team writes a Flow for a low-volume case, a lead arriving from a web form, then quietly reuses it for a high-volume one, a nightly import of ten thousand leads. The Flow chokes, someone blames Flow, and the whole thing gets rewritten in Apex. The right move is rarely a full rewrite. It is to detect the volume context and skip the non-bulk-safe elements when invoked from a bulk source, or to wrap the Flow in an invocable Apex method that handles bulkification before delegating back.
Flow does scale, up to roughly the volumes where a thoughtful Apex implementation also begins to strain. Above that point Apex pulls ahead, because it can become a queueable job, a scheduled batch, or a platform-event subscriber. Flow can call those things but cannot be them, and that is the real ceiling.
06 / REFACTORWorking through a legacy org
If you have inherited an org with five hundred Apex classes accumulated over a decade, do not migrate everything to Flow. Most of those classes are doing fine. The refactor that pays off is narrow: find the Apex triggers doing simple field updates or status transitions, many of which predate Flow being good at these things, and replace those with record-triggered Flows so the next administrator can change the logic without an engineering ticket. Leave the genuinely complex classes where they are.
For every Apex trigger you are considering moving to Flow, time how long it takes to explain what it does to a non-developer. If the explanation runs past two minutes, it is not a Flow candidate. Keep the Apex.
The point of the matrix is not to crown a winner. It is to stop teams from burning three weeks rewriting working code on the strength of a tool preference. Pick the right tool for the quadrant, ship it, and move to the next problem. That discipline is worth more than any allegiance to either side.