Published on 7 September 2026 · 6 min read
Flow or Apex? When Salesforce automation needs code
A practical decision guide: what Flow does well, where it breaks down, and when Apex is the right tool. With examples.
Salesforce gives you two ways to automate: Flow, the declarative tool, and Apex, the programming language. The official guidance is "clicks before code", and it is right most of the time. But "most of the time" is not "always", and choosing wrong in either direction is expensive. This is the decision guide I use on real projects.
Flow or Apex: the comparison in one table
The short version, before the detail: pick Flow when a non-developer must be able to change the rule, Apex when volume, complexity or error handling would make a Flow fragile.
Who can change it later
Flow: An admin, from the Setup UI
Apex: A developer, with a deployment
Bulk volumes
Flow: Fine up to moderate volumes; slows down on large batches
Apex: Built for bulk: thousands of records per transaction
Complex or branching logic
Flow: Becomes hard to read past a dozen elements
Apex: Readable and reusable if it is written properly
Calls to external systems
Flow: Possible, with limited error handling
Apex: Full control over retries, timeouts and errors
Automated tests
Flow: None built in: scenarios must be run by hand
Apex: Required, and they catch regressions for years
Time to first version
Flow: Hours
Apex: Days
Cost to maintain
Flow: Low while it stays simple, high once it sprawls
Apex: Predictable, provided tests exist
Best fit
Flow: Business processes that change often
Apex: Rules that must be right at scale
What Flow does well
Record-triggered logic on a single object: updating fields, creating related records, sending emails and notifications, posting to Chatter.
Guided screens for users: wizards, data entry with validation, approval requests.
Scheduled jobs with simple logic: nightly updates, reminders, status changes.
Orchestration of existing pieces: calling invocable actions, subflows and simple external services.
Flow is visible to admins, changes fast and needs no deployment pipeline for small tweaks. When the logic fits in one readable canvas, Flow is the right answer.
Where Flow breaks down
Complex logic: nested conditions, loops inside loops, many objects touched in one transaction. The canvas becomes unreadable and untestable.
Large data volumes: Flow has its own limits and is harder to bulkify correctly; batch processing of hundreds of thousands of records belongs in Apex.
Order of execution: when several flows and triggers fire on the same object, debugging becomes guesswork. A single trigger handler with an explicit order is easier to reason about.
Error handling and retries: fault paths exist, but sophisticated retry logic, logging and partial rollbacks are far cleaner in code.
Reuse and testing: Flow has no unit tests. Apex does, and Salesforce enforces 75 percent coverage for a reason.
When Apex is the right tool
Business logic that must be reliable, tested and versioned: pricing engines, allocation rules, complex validations across objects.
Integrations with external systems that need authentication, retries, pagination or payload transformation.
High-volume batch and asynchronous processing.
Custom user interfaces with Lightning Web Components that need server-side logic.
Anything an admin should not be able to change by accident.
A simple rule of thumb
If the automation can be explained in one sentence and touches one object, use Flow. If it needs a diagram to explain, involves several objects or an external system, or must be tested, use Apex, and keep Flow as the thin layer that calls it. Mixing the two well is a skill: keep triggers in one framework, keep flows small, and document which one owns each object.
Not sure which you need?
Describe the automation you have in mind and within one business day you get an answer on whether it is a Flow, an Apex job or a bit of both, with a fixed-price quote either way.
Key points
- "Clicks before code" is right most of the time, and expensive the rest of the time.
- Move to Apex when volumes are high, logic is branched, or you need real error handling on callouts.
- Never split the same business rule across a Flow and a trigger: pick one owner per object.
- Apex comes with tests; Flow does not, so complex Flows need their own documented test scenarios.
Related services
Need this done in your org?
Describe your need and get a written quote within one business day.
Get a free quoteWritten by
Leonardo Marchitelli
Founder
Founder of Cloud Atelier, an IT consulting studio based in Rome.