Salesforce Flow vs Apex in 2026: The Decision Framework Nobody Gave You

Every Salesforce team hits the same wall. You've got a requirement. It could be a Flow. It could be Apex. Nobody can give you a straight answer on which one to pick.

So someone picks the one they're more comfortable with. Three months later, you're either debugging a Flow that looks like a plate of spaghetti, or maintaining an Apex class that could have been a three-node Flow.

This isn't a religious debate. It's a tooling decision. And the landscape just shifted.

What changed in 2025-2026

Workflow Rules and Process Builder are dead. End-of-life was December 31, 2025. You can't create new ones. Existing ones still run, but they're on borrowed time. Salesforce is unambiguously Flow-first now.

Flow got massive investment across three releases. Approval Orchestration (Spring '25). AI Decision Elements (Winter '26). Vibe-Flow building — you describe what you want, Flow builds it (Spring '26). Flow Orchestration went free in February 2026.

Apex got the Cursor class (Spring '26). It queries up to 50 million records with server-side caching. For data-intensive operations, this alone can be the reason to choose Apex over Flow.

Flow testing went GA (Spring '25). You can write structured tests now. Still can't enforce coverage or run them programmatically in CI/CD — but it's no longer a black box.

These aren't incremental changes. The tooling gap between Flow and Apex narrowed significantly.

The actual limits — side by side

People argue about Flow vs Apex without knowing the numbers. Here they are:

Limit	Flow	Apex (Sync)	Apex (Async)
SOQL queries	100	100	200
DML statements	150	150	150
Query rows	50,000	50,000	50,000
CPU time	10s	10s	60s
Executed elements	2,000 per interview	N/A	N/A
Loop iterations	5,000	N/A	N/A

Flow and Apex share the same governor limits pool for SOQL, DML, and query rows. The difference is CPU time — async Apex gets 60s — and the Flow-specific element/loop caps.

With the Cursor class, Apex can query 50 million records. Flow is capped at 50,000 query rows. For large datasets, this isn't a preference. It's a hard constraint.

The decision framework

Start with Flow when:

It's a standard automation (field update, email alert, task creation)
The logic is linear or has simple branching
A business user might need to modify it later
You want it accessible to Agentforce agents (Flow is the integration point)
You need approval orchestration — Flow handles this natively now

Start with Apex when:

You need more than 50,000 records (or 50M with Cursor)
Complex data transformations or multiple object relationships
Callouts to external systems with retry logic
You need enforced test coverage in CI/CD
Async processing with 60s CPU time (Queueable, Batch)
You're building invocable methods for Agentforce

The gray area — specific scenarios

"I need to update related records when a parent changes."

Simple parent-child update? Flow. Five nodes, done.

Three levels deep with different criteria per level? Apex. Flow will work, but you'll get subflow spaghetti nobody wants to touch.

"I need to send data to an external system."

Apex. Period. Flow has HTTP callouts now. They're not production-ready for complex integrations. No retry logic. No mocking in tests. No proper error handling. Apex with @future or Queueable gives you real control over the entire lifecycle.

"I need to prevent a record from being saved based on complex rules."

Validation rule. Not Flow, not Apex — the validation rule feature. If it requires checking related records or external data, then Apex with a before insert/update trigger.

"I need to run something on a schedule."

Scheduled Flow for simple cases. Apex Scheduled jobs for complex logic or when you need to chain operations.

The maintenance factor nobody talks about

Who's going to maintain this in six months?

If your team is mostly admins, write a Flow. Even if it takes 20 nodes. Because an Apex class that nobody on the team can read is worse than a messy Flow.

A working Flow that an admin can debug beats a perfect Apex class that requires a developer every time something changes.

If your team is mostly developers, write Apex. A Flow with 50 nodes and subflows is unreadable. You can't version control it properly. You can't write unit tests. You can't diff it meaningfully in a pull request.

The maintenance decision is more important than the technical decision.

I've seen this go wrong both ways. A 60-node Flow that nobody could debug after the original admin left. A 500-line Apex class that could have been a 5-node Flow. Both were disasters. Both were avoidable.

The anti-patterns that kill Flow projects

I've seen each of these take down a production org:

DML or SOQL inside loops. The #1 Flow killer. 5,000 loop iterations × 1 SOQL = dead Flow. Use the Transform element to bulkify.
God flows. One Flow that does everything. Break it into subflows with clear responsibilities.
Ignoring fault paths. When a Flow fails without fault paths, it fails silently. Always add fault connectors.
Hard-coded IDs. They change between environments. Use custom metadata types.
Sub-flows sharing transaction limits. They share the same 2,000 element limit and 100 SOQL limit. Plan accordingly.

The hybrid approach

Most well-run Salesforce orgs I've seen use both. Flows for the 80% of automations that are straightforward. Apex for the 20% that are complex. Invocable Apex as the bridge.

Invocable Apex best practices:

Keep invocable methods thin — delegate to service classes
Always use bulkified List<Input> parameters
Populate the description field — critical for Agentforce discovery
Version your interfaces — don't change signatures, create new versions

The admin wires up the Flow. The developer owns the hard parts. Agentforce can trigger either path.

What Salesforce is actually saying

Flow PM Adam White: "Flow is the now." Not "the future." The now.

Flow is becoming the foundational automation layer. Even AI agents plug into it. Apex is not being deprecated — it's the power option. They're complementary.

But the direction is clear. Workflow Rules and Process Builder are gone. Flow is the only declarative path forward. If you're not investing in Flow skills, you're accumulating technical debt.

The bottom line

Pick based on the requirement, your team's skills, and who maintains it.

Quick cheat sheet:

Standard automation, <50K records, admin-maintained → Flow
Complex logic, large datasets, developer-maintained → Apex
Standard automation with one complex piece → Flow + Invocable Apex
External integrations → Apex, always

If you can't explain why you chose one over the other in one sentence, you don't have a reason. You have a preference. Preferences are fine — but call them what they are.

This is an independent comparison with no affiliate links. I'm not sponsored by Salesforce or any consulting firm. The views here are based on real implementation experience, not marketing materials.