The Salesforce Flow vs Apex trigger debate isn't really a debate. Flow wins when the logic is simple, single-object, and low-volume. Apex wins when you need tight control over bulk processing, complex branching, or anything touching more than one or two related objects at scale. Most teams get this wrong in one direction: they either force everything into Flow because no one wants to write code, or they default to Apex out of habit and end up maintaining triggers that a five-minute Flow could have replaced.
Every automation decision on an object eventually asks the same thing: what happens when this record gets updated 200 times in one transaction? A data import, a batch job, an API integration pushing records in bulk. Flow and Apex both run per-transaction, not per-record, so bulkification matters in both. But the failure modes are different. A poorly written Flow with nested loops and unbulkified DML inside a loop will hit governor limits just as fast as bad Apex. The difference is how much control you have over fixing it.
In Apex, you write the SOQL query once, outside the loop, and process a collection. You control exactly when queries fire and when DML commits. In Flow, the platform makes those decisions for you, and older Flow versions had real bulkification problems inside loops. Modern Flow has gotten much better at this, but it still hides the mechanics from you. If something goes wrong, you're debugging a visual canvas instead of reading a stack trace.
Flow is the right call for record-triggered logic that's linear: field updates based on conditions, sending an email alert, creating one related record, updating a parent record's rollup-style field. Admins can build it, modify it, and hand it off without a deployment pipeline. That matters more than most developers want to admit. A business rule that changes every quarter belongs in Flow, not in a class that needs a sandbox, a pull request, and a release manager to touch.
Flow also owns anything that needs a screen: guided data entry, approval-adjacent processes, multi-step forms for users who aren't developers. Apex can't do screen flows. That's not a limitation you work around, it's a different category of automation entirely.
Where Flow gets dangerous is when a team stacks five or six record-triggered flows on the same object, each built by a different admin over two years, none aware of the others. That's not a Flow problem specifically. It's an ownership problem that Flow makes easy to create because building one takes ten minutes and nobody reviews it like they'd review code.
Apex earns its keep in three places: complex branching logic across many conditions, recursive-safe processing that needs custom guard logic, and anything requiring precise control over before/after context and record state comparisons across dozens of fields. Flow can compare old and new values, but once you're checking fifteen fields for changes and running different logic branches for each combination, the visual canvas turns into something harder to read than the equivalent forty lines of Apex.
Apex also wins when the logic needs to call out to other systems in a controlled way, handle exceptions with specific rollback behavior, or process large batches with exact control over query cursors and heap size. Batch Apex and Queueable Apex exist because some jobs need that level of control. Flow's scheduled paths and record-triggered flows can approximate some of this, but they're built for a different scale of problem.
There's also a maintainability argument developers underrate: Apex is testable. You write unit tests, you assert exact outcomes, you catch regressions before deployment. Flow testing exists but it's weaker, and a Flow with six decision elements and three subflows is much harder to unit test than a class with clearly separated methods.
Here's the part most Salesforce teams learn the hard way. Before-save flows run early in the order of execution, before validation rules re-fire and before most Apex triggers. After-save flows run later, alongside before/after triggers, in an order that depends on metadata creation sequence, not on anything you explicitly control. When a Flow and an Apex trigger both fire on update, and both modify the same field, you get race conditions that are miserable to debug because the sequence isn't obvious from reading either piece of automation in isolation.
This is the single biggest reason large orgs standardize on one automation tool per object for a given trigger context. Not because Flow is worse than Apex or the reverse. Because mixing them on the same object multiplies the number of places you have to check when something behaves unexpectedly. If a record's status field is wrong after a save, you now have to check every flow and every trigger on that object, in execution order, to find the culprit.
Before-save flows are fast and cheap because they update the same record without a second database round trip. That's a real performance advantage over an equivalent before-Apex trigger, which behaves identically in this specific case. But an after-save flow that updates related records triggers a second full save cycle, which re-fires validation rules, workflow rules, and any triggers on those related records. An Apex trigger doing the same related-record update has the same cost. The tool doesn't remove the cost. It just determines how visible that cost is to the next person reading the automation.
I've seen the same pattern across dozens of orgs: an object with four record-triggered flows, two of them doing overlapping work, one of them disabled but not deleted, and an Apex trigger from three years ago that nobody remembers the purpose of because the developer who wrote it left the company. None of these pieces were wrong on their own. The problem is nobody owns the whole picture.
The fix isn't picking Flow or Apex as a permanent standard. It's picking one trigger context per object as the entry point, and routing everything through it. Some teams build a single Flow per object per trigger event, and call Apex from that Flow for the genuinely complex branches. Others go the other direction: one Apex trigger handler class per object, calling out to smaller methods, with Flow reserved strictly for screen flows and low-stakes field updates admins need to change without a deployment. Both patterns work. What doesn't work is five independent automations on the same object with no coordination.
Use Flow when the logic is linear, the volume is normal transactional volume, and the person maintaining it long-term is an admin, not a developer. Use Apex when you need bulkification control, complex multi-field branching, callouts with custom error handling, or anything that needs real unit test coverage before it ships. If you're not sure, ask what happens when 5,000 records hit this automation in one batch job. If the answer makes you nervous, write it in Apex.
| Situation | Better fit |
|---|---|
| Single field update on record save | Flow |
| Screen-based data collection | Flow |
| Complex branching across 10+ fields | Apex |
| Bulk data load via integration | Apex |
| Callout with custom retry logic | Apex |
| Admin needs to change logic without deployment | Flow |
None of this is about which tool is more modern or which one Salesforce is investing in. Flow gets more platform investment every release, and that's fine. It doesn't change the underlying question, which is what the automation needs to do reliably at the volume your org actually runs at, not the volume it ran at when someone built the first version two years ago.
No. Flow has absorbed a lot of the simple automation use cases that used to require Apex, like Process Builder before it. But complex bulk processing, custom exception handling, and heavy multi-object branching logic still belong in Apex. Salesforce keeps investing in Flow's capabilities, but it hasn't closed the gap for genuinely complex logic.
They can coexist, but they need to be coordinated deliberately. Before-save flows and Apex before triggers run early in the order of execution, and after-save flows run later alongside after triggers, in a sequence that depends on metadata creation order. Without coordination, both automations can update the same field and produce race conditions that are hard to trace.
A before-save Flow updating the same record is roughly as fast as a before Apex trigger doing the same thing, because both avoid a second database round trip. Anything that touches related records, whether built in Flow or Apex, triggers a second save cycle and re-fires validation and automation on those records. The performance cost comes from the operation type, not the tool.
This usually happens when automation gets built over years by different admins and developers without a shared standard. Each person solves their immediate problem without checking what already exists on the object. The fix is auditing every automation on high-traffic objects and consolidating to one entry point per trigger context.
Default to Flow for simple, linear, low-volume automation and anything an admin needs to maintain without a deployment pipeline. Default to Apex for complex branching, bulk processing, callouts, and anything that needs real unit test coverage before release. Most healthy orgs use both, with clear rules for which situations go where.