Salesforce
Salesforce Flows Are Eating Your Apex
Declarative automation has quietly crossed a threshold. Here is how I decide what still belongs in code — and what no longer does.
For years the rule of thumb was simple: anything non-trivial belongs in Apex. Flows were for admins, code was for engineers, and the line between them was a line between toys and tools. That line has moved, and most teams have not noticed.
The threshold we crossed
Modern Flow handles bulk, handles errors, handles subflows and reusable actions. It is testable, sort of. It is version-controlled, finally. The cases where Apex is strictly necessary have shrunk to a real but narrow band: heavy computation, complex transaction control, and anything that has to talk to the outside world with nuance.
The question is no longer "can I build this in Apex?" It is "should this be code at all?"
How I decide now
I reach for Apex when I need precise control over the transaction, when the logic is genuinely algorithmic, or when an integration demands it. Everything else — the long tail of "when X then set Y" — belongs in a Flow that an admin can read, change, and own. The win is not fewer lines. It is putting the change next to the person who understands the requirement.