Two Things Before We Start
Right, this one’s going to be a bit spicier than usual, so let me set the ground rules.
1. When I say “clicks,” I mean low code automation tools. Workflow rules, Process Builder, and Flow, primarily. Not the declarative platform generally. I am not about to argue that you should write Apex instead of creating a custom field, which would be insane.
2. This is an opinion piece. It’s shaped by my experience across 47 Salesforce implementations over close to seven years. Your experience is different from mine. You may agree, you may not, and that’s genuinely fine.
So before you go and tear down every automation in your org, assess your own situation. What’s right for your org matters more than what’s been true in mine.
With that said, let’s get into it.
The Argument
My position is that for orgs that are growing, code scales better than low code automation, and the crossover point arrives earlier than most people expect.
Here’s why.
1. You Can’t Control Execution Order
This is the big one.
Have three Flows on an object and you cannot reliably control which runs first. Salesforce has added trigger ordering to record-triggered Flows, which helps, but the general problem remains: as automation accumulates from different people at different times, the interactions become unpredictable.
With Apex you have a trigger framework, one trigger per object, and explicit control over the order everything executes in. You can read the file and know exactly what happens.
In an org with fifteen automations on Opportunity, “what actually happens when I save?” should be an answerable question. With code it is.
2. Testing
Apex requires 75% coverage to deploy. Which feels like a burden right up until you realise what it buys you: a regression suite that runs automatically on every deployment.
Flows have no equivalent requirement. You can deploy a Flow that breaks three other processes and find out from a user.
I’ve written about what makes a genuinely good Apex test, and the argument there applies double here. Tests aren’t a tax, they’re what lets you change things confidently.
3. Version Control And Code Review
Apex is text. It diffs. You can review it in a pull request, see exactly what changed, and roll back cleanly.
Flow metadata is XML that technically diffs and is genuinely unpleasant to read. Reviewing a Flow change in a pull request is nobody’s idea of a good time, so in practice most teams don’t, which means changes go in unreviewed.
Once you’ve got a CI/CD pipeline, code fits that workflow naturally. Flows fight it.
4. Bulk Behaviour
Flows are better at this than Process Builder was, but it’s still easy to build one that quietly does a query per record.
In Apex, bulkification is explicit. You can see the loop. A reviewer can spot the mistake. Static analysis tools will flag it automatically.
With a Flow, you find out when somebody bulk loads 10,000 records and everything falls over.
5. Reuse
In Apex, logic used in five places lives in one method. Change it once.
In Flow, that logic tends to get rebuilt in each Flow that needs it. Subflows exist and help, but the gravity of the tool pulls towards duplication. And when the business rule changes, you’re hunting for every copy.
This is the Single Responsibility argument again, and it applies to automation just as much as to classes.
Where I’m Wrong, Or At Least Where Clicks Win
I’d be doing you a disservice if I only made one side of this argument.
Small orgs genuinely don’t need this. If you’ve got two automations on Opportunity and no developer on staff, Flow is absolutely the right answer. The overhead of a code-based approach isn’t worth it.
Admins can maintain Flows. This is a real and significant advantage. If your only developer leaves, your Flows keep being maintainable and your Apex doesn’t.
Screen Flows have no code equivalent. Building a guided UI declaratively is genuinely faster than an LWC, and often good enough.
Speed of delivery. A simple field update is faster in Flow. It just is.
Salesforce is investing heavily in Flow and it keeps improving. Some of my complaints have already been partly addressed and more will be.
What I’d Actually Recommend
Not “always use code.” That would be as silly as “never use code.”
Pick one tool per object and stick to it. The genuinely unmaintainable orgs aren’t the ones using Flow, or the ones using Apex. They’re the ones using both on the same object, where nobody can work out what runs when.
Use Flow for simple, isolated automation. Field updates, simple notifications, screen flows.
Use Apex when logic is complex, order matters, it’s reused, or volume is high.
Decide the threshold up front and document it. “Anything touching more than two objects goes in Apex” is a rule a team can follow. Deciding case by case is how you end up with both.
Be honest about your team. If nobody can maintain Apex, don’t build a codebase that becomes unmaintainable the moment your contractor leaves. That’s a worse outcome than a slightly messy Flow.
My position remains that as an org grows, the arguments favour code more than most people expect. But the worst answer is having no position at all and letting both accumulate for five years. Pick a strategy, write it down, and apply it consistently.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
