6 min read
Flow versus Apex gets argued as a capability question, and framed that way Apex wins every time — it can do strictly more. But capability is rarely the binding constraint on a mid-market org. Maintainability is. The tool that matters is the one your team can still safely modify long after whoever built it has moved on.
The rule of thumb
Build it in Flow unless the requirement crosses one of a small number of hard lines. If it does, write Apex deliberately, document why, and keep the coded surface as small as the requirement demands.
Stated that way it sounds like a preference for clicks over code. It is not — it is a preference for the smallest tool that fully meets the requirement, because every line of Apex is a line that needs test coverage, a deployment, and a developer the next time the business changes its mind.
When Flow is the right answer
Most business process automation lands here, and it should.
- Field updates, record creation, and related-record maintenance driven by a change on a record.
- Approval routing, task and notification generation, and stage progression.
- Screen-based data entry and guided processes for a specific role.
- Scheduled batch work over moderate record volumes.
- Anything an admin will foreseeably need to adjust as the process evolves.
When it genuinely has to be Apex
These are the lines worth crossing, and they are narrower than most orgs assume.
- Bulk operations at volumes where declarative processing hits governor limits or runs too slowly to be practical.
- Logic that must run transactionally with precise rollback behaviour across multiple objects.
- Complex recursion, ordering, or branching that Flow can express only as an unreadable sprawl.
- Callouts and integration logic needing real error handling, retries, and idempotency.
- Reusable business logic that several entry points must share without being duplicated.
The grey zone, and how to settle it
The honest grey zone is the requirement that Flow can technically do, but only as a twenty-element branching diagram nobody will want to open. A Flow that no admin can read has lost the advantage that made Flow the right choice — at that point Apex with tests and comments is often the more maintainable artifact.
A useful test: can you describe what this automation does, out loud, in two sentences? If yes, Flow. If describing it requires a diagram, the complexity is real, and the question becomes whether to simplify the process or commit to code. Simplifying the process is usually the better answer and almost never the one on the table.
Why maintainability is the tiebreaker
Automation is not finished at go-live; it is inherited. Someone will need to change it when a team reorganises, a field is added, or a release tightens a default. The cost of that change is decided by which tool you picked, and it is paid for years by people who were not in the room.
Pick the tool that keeps the next change cheap. That is the whole rule, and every line above is a consequence of it.