Flow vs. Apex: When to Use Which
One of the most common questions in Salesforce development — should you build it in Flow or write Apex? Here's a practical decision framework.
One of the most debated questions in the Salesforce ecosystem: should I build this in Flow, or write it in Apex? Both can automate business logic, both can query and update records — but they’re not interchangeable, and choosing wrong costs you later.
Here’s the practical framework we use with every client.
Start with Flow — unless you have a reason not to
Salesforce’s official stance is “clicks before code,” and it’s good advice for a reason. Flow is:
- Declarative — no deployment needed, admins can maintain it.
- Visible — any certified admin can open it and understand what it does.
- Faster to ship — no test classes, no scratch org setup, no PR review cycle.
- Safer in hands-off orgs — clients who don’t have a developer on retainer can tweak it themselves.
If the logic fits in a Flow without gymnastics, use Flow.
When Apex is the right call
Flow has hard limits that matter in production. Switch to Apex when:
1. You’re hitting governor limits
Flow is not bulk-safe by default. A single record trigger is fine; 10,000 records in a data load is not. Apex gives you explicit control over SOQL and DML bulkification.
2. Complex logic that Flow can’t express cleanly
Nested loops, recursive logic, custom sorting algorithms, dynamic field references — these are possible in Flow but become unmaintainable rats’ nests. If you’re fighting the tool, the tool isn’t right.
3. Callouts and integrations
Flows can make HTTP callouts, but they’re limited to synchronous paths and can’t handle retries, error parsing, or authentication flows gracefully. Apex with @future or Queueable gives you full control.
4. Performance-sensitive paths
A Record-Triggered Flow on a high-volume object (orders, log records, IoT events) can add meaningful latency and hit CPU limits. Apex, written carefully, is faster.
5. You need to unit-test the logic
Flow has no unit test framework. If correctness matters — financial calculations, compliance logic, anything that touches money — Apex lets you write deterministic tests with known inputs and outputs.
The hybrid approach
The best Salesforce orgs use both. A common pattern:
- Flow handles the orchestration: when to run, which records to process, simple field updates and notifications.
- Apex is called by Flow (via invocable methods) for the heavy lifting: bulk queries, external callouts, complex calculations.
This gives you the visibility of Flow with the power of Apex. Admins can read the flow and understand the process; developers own the logic that needs to be tested and optimized.
A quick decision checklist
| Question | If yes → |
|---|---|
| Will this run on more than ~200 records at a time? | Apex |
| Does it involve HTTP callouts with retries? | Apex |
| Does it need deterministic unit tests? | Apex |
| Can an admin maintain this without developer help? | Flow |
| Is it a simple field update or notification? | Flow |
| Is it a one-off fix with no future complexity? | Flow |
The honest answer
There’s no universal right answer — it depends on your org’s volume, your team’s skills, and your maintenance model. What we always avoid: complex multi-level Flow loops on high-volume objects, and Apex doing things that a simple Flow assignment would handle fine.
When in doubt, build it in Flow first. If it starts to hurt, refactor to Apex. The cost of doing it wrong is rarely the initial build — it’s the maintenance two years later.
Have a specific automation question? Get in touch — we’re happy to take a look at your use case.