Salesforce Flows are undoubtedly powerful, and like anything popular, they attract a fair amount of criticism. As a huge topic, it’s perhaps inevitable that the debate about Flow vs. Apex often focuses on the surface impact, overlooking the deeper meaning and long-term effects that a new and emerging tool can have on our ecosystem.
In this opinion piece, I’ll explore the roots of the criticism of Flow and discuss what we, as an ecosystem, can do to turn the ship around.
How Did We Get Here?
My first encounter with Salesforce flows was around 2012 when I was a Tier 2 Salesforce Support Representative at Fujitsu Consulting in Costa Rica. At that time, Salesforce outsourced all non-Tier-3 support to Fujitsu and other consulting firms. My area of expertise was Salesforce Setup, which included workflows and a complex and somewhat weird tool called the Cloud Flow Designer.
The Cloud Flow Designer (CFD from now on) was the original Salesforce Flow. It was a Flash-based drag-and-drop UI, similar to today’s Flow Builder, but it looked very different and had very limited capabilities.
If I remember correctly, customers needed to buy a specific feature license to access the CFD. Back at Fujitsu, no one knew how to support the CFD, and I, being an ambitious young man, saw this as an opportunity to stand out among my peers. I can’t recall exactly how I learned about the CFD, as Trailhead didn’t exist back then. I suppose I used one of those long PDF guides that were common at the time.
Over time, I became the go-to person for CFD-related issues at Fujitsu. I think one reason I was able to ‘get’ CFD was that I was somewhat familiar with programming concepts. At the time, I was studying Cisco networking and PowerShell scripting, so the concepts of variables, loops, and flow control weren’t entirely new to me, though I wasn’t a programmer by any means.
At the time, the CFD was a luxury. Not all customers had it, and not everyone understood it well. Fast forward to today, 12 years later, and the story is completely different. Today, flows are present in almost every Salesforce implementation. They are almost on par with Apex in terms of features and capabilities and can offer very powerful UI experiences. You have loops, complex DML operations, HTTP callouts, LWC integration, and much more.
Flow is also free to all customers now, and while some may still find it intimidating, it’s no longer the odd tool I encountered back in 2012.
It’s hard to pinpoint exactly how or when Flow became what it is today – so powerful and prominent. It almost seems like it happened right in front of us without anyone noticing. Suddenly, one day, Flow became a big deal. It evolved from being a simple, exclusive drag-and-drop UI to one of the most powerful low-code tools in the industry and a major differentiator for Salesforce.
Salesforce is also investing heavily in Flow, with every release packed with new features and a product manager who is very active in Salesforce social media circles. Make no mistake – Flow is powerful and is here to stay.
However, while this emerging tool is welcomed by many, there are worries about what the future holds. In my experience, most of these worries come from the Salesforce Developer community, and well… It’s complicated.
Why Are Developers Concerned About Flow?
The best thing about Flow is that almost anyone can create a complex business process with a simple drag-and-drop UI.
The worst thing about Flow is that almost anyone can create a complex business process with a simple drag-and-drop UI.
This is not a typo. Flow gives almost anyone unlimited power, and you know the saying: “With great power comes great responsibility”. In the past, only Salesforce Developers could craft such complex processes thanks to Apex. Developers saw themselves as the elite, the only ones who had access to create truly amazing experiences. Now, that power is diluted.
As I said earlier, there’s a lot of criticism in the Salesforce community about Flow, and a good portion of that criticism comes from developers. Some think this is a form of elitism or gatekeeping, and while there’s probably some truth to that, it’s actually more complicated.
The main criticism appears to be that while Flow offers almost unlimited power to anyone who can drag and drop boxes on a screen, it doesn’t provide the necessary guardrails to prevent vulnerabilities, data corruption, or the fair use of Salesforce Governor Limits. Additionally, Flow’s awkward XML representation makes it almost impossible to integrate into a typical Salesforce CI/CD pipeline. However, most concerning is that flows can be edited directly in production, just like that. This means anyone with admin access can quickly create a Flow that (by mistake) deletes, corrupts, or compromises production data.
In contrast, writing Apex is a lot harder for the general population. This means that not anyone can write Apex. You need special training and a solid understanding of programming. Apex also comes with a robust testing framework that allows you to test your code, and it can be easily added to a Salesforce CI/CD pipeline with pull requests and standard approvals. This means that, in general, Apex offers much more support for enterprise security and adherence to strong development standards.
Notice the emphasis on the word “offers”. Just because Apex offers more guardrails doesn’t mean that Apex is inherently better than Flow. If you’ve been developing on the platform for a while, you would have one or two horror stories about Apex code – that is a big ball of mud, an untangled mess that no one can understand, let alone dare to change! So, using Apex does not guarantee anything.
But what about the code coverage enforcement?, you ask. That is simply code coverage enforcement – it says nothing about the validity, accuracy, and completeness of those tests. You can have 90% test coverage without actually testing your business logic.
So, if Apex isn’t guaranteed to produce better results than Flow, what are we actually arguing about?
New Abstractions Take Time to Sink In
Flow is a higher level of abstraction that allows us to think about complex problems with a relatively simple UI, and humans have a record of opposing new abstractions. Abstraction sounds like a complicated topic, but it isn’t. Abstraction is when we use a mental map to make sense out of something that would otherwise be (more) complex.
An example of abstraction is when you see a map in a zoo or amusement park. That map isn’t an accurate representation of the actual distances between attractions – it’s a simple mental model to help you find where you are and figure out the path to the next attraction.
Such a map would be useless to an architect tasked with expanding the park. Likewise, if you were provided with an architectural map to find your way in the park, you’d probably have a hard time reading it because it exposes too many details that are unnecessary to you. The amusement park map is at a higher level of abstraction compared to the architectural map. Abstractions are needed so that we can focus on what matters instead of getting bogged down by the details.
What does this have to do with Flow? Flow operates at a higher level of abstraction than Apex. While in Apex, we have to carefully type every single character, every variable, and every method; with Flow, a lot of it comes built-in, and you just have to fill in the blanks.
Every time a new and higher level of abstraction appears, people resist. For example, programmers of the C language had to manage memory allocation by hand. When newer languages came up, like C++, which automatically took care of memory allocation, many people complained and said, “Real developers can manage memory allocation”.
And now, a new and even more powerful level of abstraction is rising – AI. For many tasks, we just need to focus on understanding the problem at a high level, and AI can figure out the details. How have people reacted to AI? In the same way, “Real writers don’t use AI”, “Real developers don’t use AI”, and so on…
This is just history repeating itself. Some of the criticism against Flow originates from our natural resistance to higher levels of abstraction that hide details from us. We fought hard to learn how to deal with those details, and when something comes that can make those details somewhat irrelevant, we feel as if something is being taken away from us.
This isn’t to say that the criticisms against Flow are purely psychological, as there are clear disadvantages compared to Apex. However, how we think about these disadvantages is part of the problem. One could also argue that the benefits AI offers are orders of magnitude more tangible than those of Flow, but I’d still argue that we are prone to resist new abstractions.
Tech Debt Comes Mainstream
There’s no shortage of social media posts criticizing Flow – many have been written by me! A valid question I’ve seen asked is why people don’t criticize Apex as much as Flow. After all, poorly written Apex code can also delete, corrupt, or compromise production data. So, why does Flow get all the scrutiny?
My theory is that because the barrier to entry for Flow is considerably lower than for Apex, we are witnessing higher levels of technical debt and poor design. This isn’t to say that those who create flows lack design skills (that’s really not what I’m saying), but because the ease of use can sometimes lead to less meticulous design practices.
Previously, technical debt in Salesforce was mostly associated with poor design in Apex code and a poor data model (hundreds of unused fields, too many relationships, etc.). Now, technical debt is becoming more visible in the ecosystem as it manifests in flows with hundreds of elements, too many decision points, and other complexities. Before, such poor design decisions were primarily visible to developers and architects.
Some also express concern that Salesforce themselves don’t do more to educate the community on how to properly apply software development principles to flows. In contrast, there are many recipes for good design practices for Apex code that Salesforce themselves support.
Can We Turn the Ship Around?
Let’s summarize the situation we find ourselves in:
- A ‘new’ tool has emerged and disrupted the space.
- Almost anyone can use it, which is a double-edged sword.
- Some parties are concerned about the lack of guardrails and the lower barrier of entry.
- We naturally resist new things, especially when the tradeoffs between benefits and costs are not always clear.
So, is it all doom and gloom? Can we, as an ecosystem, fix this problem? I believe the solution is two-fold…
First, we need to come up with an automation framework that can scale – one that companies can start using from day one. Most enterprise frameworks are that… enterprise frameworks. They only work once you reach a certain level of complexity, and by then, it’ll take a substantial amount of time for the framework to show its benefits.
We need a framework that grows and scales with the customer. Such a framework should provide clear guidelines and recipes for how to use all the automation tools available in a way that you get the most out of all of them, given certain constraints and circumstances.
The ecosystem is slowly but surely moving already in this direction. Pratibha Sundar is the creator of the Reusable Record-Triggered Flow Framework, a fantastic framework that brings software engineering principles such as modularity and reusability into the Flow universe. If you haven’t gone through the framework, I highly recommend you do so. But don’t stop there – think about what else the framework can benefit from and what other software engineering patterns we could include in it.
This brings us to the second part of the solution…
We need to start thinking like software engineers. Salesforce was created with the sole purpose of bypassing IT and letting business users run the game. That works for very small companies, but once a certain complexity is reached, Salesforce must be treated as what it really is: software.
As such, we owe it to ourselves and our employers to start adopting a software engineering mindset. This may sound intimidating, especially for those of us who don’t have a Computer Science degree (I studied Criminology). There are countless books and courses aimed at helping non-technical people to adopt a software engineering mindset. One such book is The Phoenix Project. I’m sure there are many more you can quickly find on Amazon and Audible. If we have the time and energy to get Salesforce certified, then we also should have the time and energy to develop the skills to think in terms of software.
Once we have a software engineering mindset, we will truly understand frameworks like Pratibha’s. We will also be able to create our own frameworks that embrace battle-tested software design principles.
Conclusion
Flow isn’t going anywhere. Many of us don’t like it – some reasons are valid and technical, others are messy and perhaps emotional. But it is here to stay.
We are still in the early stages, and we can do a lot to prevent Flow from becoming the new technical debt enabler. We can do so by coming together and embracing the reality of Flow and Salesforce: it’s software.
Comments: