Salesforce's 'clicks, not code' mantra is brilliant marketing, but it has created a dangerous trap for growing orgs. We regularly see complex business logic shoehorned into massive, unmaintainable Flows simply because the team lacked Apex expertise. Knowing when to cross the threshold is the difference between a scalable org and a fragile one.
Let's be clear: declarative tools — Flow, Validation Rules, Formula Fields, Custom Metadata — are the right starting point for the vast majority of Salesforce automation. They are faster to build, easier to maintain by non-developers, and do not require deployment pipelines. For most business logic, Flow is the correct answer.
The problem is not that teams use Flow. The problem is that teams use Flow for everything, including scenarios where it creates more complexity and risk than a clean Apex solution would.
Flow runs in a managed transaction context, but it does not give you the fine-grained control that Apex does. When you need to handle partial saves, complex rollback scenarios, or operations that span multiple objects with interdependencies, Apex with proper try-catch-finally blocks and savepoints is the right tool. Flow's error handling is improving, but it is not a substitute for programmatic transaction control in complex scenarios.
Flow handles bulk operations, but it does so by running the flow once per record in a loop — which means your flow logic needs to be designed for bulkification from the start. When you have complex logic that needs to process collections of records with cross-record dependencies, Apex's native collection processing is cleaner, more performant, and easier to reason about.
Flow's HTTP callout capability is functional for simple REST integrations, but for anything involving complex authentication, retry logic, response parsing, or error handling, Apex is dramatically more capable. When you are building a production integration with an external system, use Apex with proper async patterns (Queueable, Batch, Future) and robust error handling.
When a Flow exceeds roughly 30 elements and requires multiple decision branches, subflows, and complex variable manipulation, it is time to ask whether Apex would be cleaner. A well-structured Apex class with clear method names and comments is often more readable and maintainable than a complex Flow diagram. The "no code" argument loses its value when the visual complexity of the Flow exceeds the cognitive load of reading clean code.
The best Salesforce orgs use both. Flow handles the declarative logic — field updates, simple notifications, guided user experiences, and standard automation. Apex handles the complex logic — integrations, bulk processing, complex business rules, and anything that requires precise transaction control. The key is knowing which tool to reach for and why.
A useful heuristic: if you are spending more time working around Flow's limitations than you are building the actual logic, switch to Apex. If a junior developer would struggle to understand your Flow diagram, it is probably time to refactor it into code.
Balancing declarative and programmatic solutions is a skill that comes with experience. If your team is stretched thin and you are not ready for a dedicated development partner, tools like RevKit.ai can help optimize your existing operations while you plan your technical roadmap.
Our team of certified developers builds clean, scalable Apex and LWC solutions. Book a discovery call to discuss your technical architecture, or get an instant quote for custom development.