When should I use Flow versus Apex in Salesforce?

Read Time: 5 Minutes

‍

‍

Most Salesforce admins waste hours debating Flow versus Apex when the decision should take 30 seconds.

Short answer: Use Flow for declarative automation under 200 records per transaction, simple branching, and standard CRUD. Use Apex when you need callouts, complex loops over 10000 records, transaction control, or logic Flow cannot reach. The 4 deciding factors are data volume, complexity, maintainability, and who owns it long-term.

This decision shapes every automation you ship for the next 5 years. Pick wrong and you inherit a haunted org no one wants to touch.

The 4 questions that decide it

Run every automation idea through these before you build a single screen.

1. Does it process more than 10000 records in one transaction? If yes, you need Apex bulkification. Flow will hit governor limits.
2. Does it need an external API callout, recursive logic, or custom SOQL with subqueries? If yes, Apex.
3. Will an admin own it 2 years from now? If yes, Flow. Apex with no owner becomes dead weight.
4. Can a 1-line change in business rules be made without a developer? If yes, Flow keeps you fast.

3 yes answers for Flow means ship it in Flow. 2 or more for Apex means it belongs in code.

Where Flow always wins

Flow is the right call for 80% of automation work in a healthy ops team.

• Record-triggered updates on Account, Contact, Opportunity, Lead, and Case objects.
• Screen flows for guided sales actions, like creating a renewal opportunity from a parent deal.
• Scheduled paths for SLA reminders, expiring contracts, and quarterly renewal tasks.
• Approval routing with dynamic approvers based on deal amount, region, or product line.
• Standard cross-object updates, like rolling Opportunity stage to Account health score.
• Outbound email actions tied to status changes, with templates and merge fields.

Flow lets your admin ship in an afternoon. Apex needs a developer, a sandbox, a deployment, and code review. The 5x speed difference compounds across 50 automations a year.

Where Apex earns its complexity

Apex is unavoidable when you push past Flow governor limits or need control Flow does not give you.

• Bulk data jobs over 10000 records, like nightly territory rebalancing or mass account hierarchy updates.
• Callouts to external APIs with retry logic, custom auth headers, or paginated response parsing.
• Complex matching and dedupe logic that needs custom SOQL with subqueries and aggregate functions.
• Trigger ordering control where the sequence of before-insert and after-update operations matters.
• Custom REST endpoints for inbound integrations from ZoomInfo, Outreach, or your own product backend.

I had a client try to bulk-update 47000 records with a record-triggered Flow. It locked the org for 3 hours and rolled back. Apex with batch processing finished the same job in 12 minutes.

The hybrid pattern that scales

The cleanest orgs I audit do not pick one or the other. They use Flow as the orchestrator and call Apex actions for the heavy lifting.

1. Build the trigger logic in Flow so admins see what fires when, on which object, with which conditions.
2. Wrap complex Apex logic as an invocable action with a clear name like "Calculate Renewal ARR" or "Match Account by Domain".
3. Call the invocable action from Flow with typed inputs and outputs.
4. Document which scenarios need the Apex path on the Flow description itself, in plain English.

A real example from a client last quarter. Their renewal Flow detects deals closing in 60 days, calls an invocable Apex action that pulls usage data from the product backend, and writes the suggested renewal price back to the Opportunity. The admin sees the Flow logic. The developer owns the Apex action. Both can sleep at night.

This pattern keeps your business rules visible to the admin who has to debug them at 4pm on a Friday. The hard parts stay in Apex where the developer can test them properly.

The 3 traps to avoid

I see these 3 anti-patterns in nearly every inherited org I audit.

• Mixing Process Builder, Workflow Rules, and Flow on the same object. Pick Flow. Migrate the rest. Process Builder is being removed by Salesforce, and Workflow Rules cannot match modern Flow capability. Two automation engines firing on the same record will fight, and you will spend Monday morning untangling which one wrote the wrong value.
• Apex triggers without a handler class. Every trigger should be a thin shell that calls a handler with a clear single responsibility. Otherwise you cannot test, debug, or reason about the order of operations.
• Flow loops over collections of more than 200 records without bulkification. The Flow runs fine in your sandbox with 10 test records and dies in production with 5000. Always test with realistic data volume before you ship.

Bottom line

Default to Flow. Reach for Apex only when Flow cannot do it. Audit your org this week and pull the 5 oldest automations on each object. Decide which to keep, refactor, or retire before they cost you a 3-hour outage.

Frequently asked questions

Is Flow really replacing Apex?

No. Flow is replacing Process Builder and Workflow Rules. Apex is not going anywhere. Salesforce has been clear that Apex remains the supported path for complex logic, callouts, and high-volume transactions. Flow handles the declarative layer; Apex handles the engineered layer.

What are the Flow governor limits I should know?

The 3 limits that bite first are 100 SOQL queries per transaction, 150 DML statements per transaction, and 10000 records processed per transaction. If you write a Flow that loops over more than 200 records and updates each one, you will hit these limits in production. Bulkify the Flow or move the work to Apex.

Can a Salesforce admin learn enough to write Apex?

Yes, but it takes 6 to 12 months of focused practice. The faster path is to learn invocable Apex actions written by a developer, then call them from Flow. Your admin keeps ownership of the business logic. The developer owns the engine room.

Should I migrate Process Builder to Flow or Apex?

Flow first. Salesforce has sunset Process Builder for new processes and is removing it entirely. Migrate to record-triggered Flows, not Apex, unless the original process was already pushing governor limits. Migrating to Apex when Flow would do is a 5-year regret.

Which is faster at runtime, Flow or Apex?

Apex is faster on heavy loads. Flow is faster to build. For under 200 records per transaction, the runtime difference is negligible and Flow's maintenance edge wins. Above 1000 records, Apex pulls ahead and the gap grows from there.

Want more of this? The Simply Scale newsletter drops every week: https://www.gosimplyscale.com/newsletter

About the author

Jordan Nelson is the founder of Simply Scale, a Salesforce consultancy helping B2B tech companies scale from $3M to $100M in ARR. Over 10 years in RevOps and Salesforce architecture at HealthEquity, Podium, and Divvy/Bill.com. Trusted by operators at Overjet, Clicklease, Notable, and Blitz Insurance. Writes to 6,000+ ops leaders every week at gosimplyscale.com/newsletter.