A year ago, the brilliant Pablo Gonzalez wrote a very interesting opinion piece about Salesforce Flow on Salesforce Ben, looking closely at the root criticisms of Flow at the time.
Fast forward to now, and I’d love to share my own thoughts on Salesforce Flow off the back of what Pablo discussed. There’s quite a bit where I agree with what Pablo has said, and a few things I’d like to offer an alternative view on. Strap in, and let’s go on a voyage into Salesforce Flow!
My Two Cents
If you’ve followed my work in any capacity, you’d know I’m a big fan of Salesforce Flow and love seeing people empowered to improve their business processes using it. I also like what Pablo said in his original piece: the best and worst thing about Flow is that almost anyone can create a complex business process with a simple drag-and-drop UI.
I will quite often share Uncle Ben’s wisdom: With great power comes great responsibility (nope, not Salesforce Ben, I meant Uncle Ben from Spider-Man!). There’s absolutely no doubt that Flow is a powerful tool, and as a result, great care should be taken when using it. You can do a lot of good for a business with this much power, but you can also inadvertently do a lot of harm if you’re not careful.
I’ve not personally faced the same degree of Flow criticism from developers that it seems like Pablo has, and I won’t try and downplay what he’s experienced. That being said, I don’t believe the issue of Flow being a ‘new abstraction’ is quite as big of an issue as it may seem.
The reality is that Flow has now been around since the Spring ‘12 release, meaning it has been around in various forms for over a decade. Spring ‘19 brought the new and improved Flow Builder with a fresh new builder interface, some enhanced features, but more or less the same Visual Workflow tool we have come to know and love.
Flow may have been a relatively new abstraction some ten years ago, but it’s become an established tool in the Salesforce builder’s arsenal since then. It may not be quite as old as Apex (2006) or other tools that developers are more familiar with, but there’s no denying that Flow has a solid foundation and incredible adoption across the board.
With all that said, do I believe there are ways that Salesforce can improve the Flow tool? Absolutely! The beautiful thing about a tool like Flow is that it is always evolving, always improving, and there are always new ways to use it to add value to your business.
Do I also concur with some of the concerns that Pablo has raised? Yes. There are ways that Salesforce Flow could, and probably should, improve that would alleviate some of the pain points that Flow can cause.
Do I believe that we need to ‘turn the ship around’ as Pablo’s title suggests? No. I don’t believe that the issues he’s raised are quite as bad as he makes out, and Flow’s benefits far outweigh the negatives. With that overview out of the way, let’s dive deeper into a few important points.
Improvements Should Continue to Be Made
Flow is incredibly powerful, but there are things that should be improved for a better all-around experience. That is not to take away from the incredible work that the Salesforce Flow team has done over the years! Flow remains an incredible tool, and each change that comes solidifies its place as the most powerful tool in an admin’s toolbox. Flow isn’t going anywhere, and the continuing updates will help ensure that it is always growing and improving.
This is something that we need to continue to see. I do not doubt that Salesforce recognizes how powerful Flow and the Flow Builder are, and I truly believe that they will continue to iterate on it in future releases. We’ve recently seen a focus on Agentforce and other AI features, and many are concerned that Salesforce is pushing its development of the platform aside in favor of these shiny new AI features.
If we pay attention to Salesforce’s marketing, then you’d not be blamed for believing this. Agentforce is front-and-center at every event, in every ad, and all over social media. Taking a deeper dive, however, you’ll see that Salesforce is still hard at work perfecting the core platform.
Agentforce’s current prevalence in the ecosystem doesn’t mean that other areas of the platform – like Flow – are being left on the back burner.. In fact, Flow is used to empower Agents in this new agentic AI era by providing modular actions for them to take. Admins and other Salesforce builders will take their Flow knowledge to create Flows, which can be used by Agentforce to take direct action on behalf of their human counterparts.
Another example of Salesforce’s investment in Flow is in the Summer ‘25 release – there were so many new Flow features that I gave five bonus points instead of my usual one! Salesforce’s development of Flow shows no signs of slowing down as each release brings a flurry of new features and enhancements.
Finally, 2025 is the year that we will bid farewell to Workflow Rules and Process Builder once and for all. Salesforce has been pushing for all declarative automation to be done in Flow and has released migration tools to support the shift. Flow is becoming the do-it-all tool for any declarative automation on the platform, and is being continually improved to handle any function that the legacy tools used to do.
While we’ve seen Salesforce continue to evolve the Flow tool, it is important that we continue to see that.
Proper Flow Testing Enforcement Is Needed
One area that I believe lacks significantly with Salesforce Flow is around testing. If you’re purely a Flow builder and have never touched Apex, you may not be aware of the fact that any code you write needs to be tested before it is pushed to Production and you cannot directly write code in Production – all Apex development occurs within a Sandbox and is tested before being pushed up. This is very different from how Flow Builder works, and I believe Apex has it right here.
While previous updates have empowered users to test flows using automated testing, it is not something that works for every Flow type, nor is it required for testing to be completed before pushing a Flow to Production. If you’re feeling really lucky, you can even build a Flow directly in Production, no Sandbox required! Sure, this allows for super rapid development, but again, with great power comes great responsibility. Flow is an EXTREMELY powerful tool, and care should be taken when working with it to ensure you’re doing the right thing for your business, not just the quickest thing.
I truly believe Salesforce needs to introduce the ability to require Flow testing before deployment into Production. I’m not saying that they should enforce this across every Salesforce org – there are orgs with decades of history that would be severely impacted by this. I’m suggesting that Salesforce could offer a toggle in Automation Settings that requires Flows to pass automated testing before being pushed into Production. This could be enabled by default for new orgs, and optionally rolled out for historic orgs.
This would enable businesses to easily create and adhere to new standards, ensuring Flows go through the same (or at least similar) rigorous testing that Apex does before it plays with real-world company and customer data.
Pablo raised an incredible point in his article – Flow doesn’t provide the necessary guardrails to prevent vulnerabilities, data corruption, or fair use of Salesforce Governor Limits. While I don’t completely agree with this statement, given the recent addition of warnings inside Flow, there’s certainly some room for improvement.
For example, I tried to prove a point by using a Create Records element within a Loop and saving the Flow, and I wasn’t warned that this was not best practice. This is a perfect example of where the Errors and Warnings section could be used to intelligently provide best practice guidance to builders as they construct new Flows. I’ve seen examples of the warnings panel giving some good pointers, so it would be good to see this more fleshed out.
It would also be a welcome change if Salesforce allowed businesses to set requirements for Flows before they are pushed to Production – not just enforced testing to make sure they function as expected, but enforcement of basic best practices. The Create inside Loop example that I used before? Imagine this failing ‘Architectural Testing’ when I attempt to push to Production. This would alleviate a lot of the issues that Pablo raised with Flow, and I believe also offers a level of architectural protection that Apex doesn’t have yet.
What About Map Collections?
If you’ve been following me for a while, worked with me on a project, or even lived next door to me (my poor neighbors!), then you’ve heard me complain about a lack of native support for Map Collections in Salesforce Flow. There’s no simple way of configuring a key-value pair in a Flow like there is in Apex. Yes, there are workarounds and ways to achieve a similar functionality, but there’s nothing as simple and easy to set up as a Map in Apex.
There are features in Apex that just aren’t so simple within Flow without a custom or third-party Apex Action or some double-loop hack. I love that Flow is simple and easy to use, but why don’t we have an Advanced SOQL element yet? This would give us the ability to add a new, flexible pink DML element to the canvas that allows us to fully leverage the power of SOQL and dynamically define output variables. What about a native JSON serializer/deserializer? These are stacks that we may see in future releases to satisfy developers and advanced Flow builders, but good things take time!
Flow has grown a lot in recent years. As Pablo mentions in his post, we now have features such as HTTP Callouts, LWC integration, and Screen Flows that have reactive components. While I’m impatiently excited for the advanced features I mentioned above, I also know that Salesforce has an internal prioritization process that must be adhered to so that most people will be kept happy.
Meanwhile, we Flow enthusiasts will continue to get excited about new, advanced features with every upcoming release and will keep our fingers crossed for the updates we’re most excited about!
Is It All That Bad?
Pablo suggests that we’re in a spot of ‘doom and gloom’, but I have a different opinion. I will concede that Salesforce Flow is similar yet still very different from Apex and other programmatic tools, but this isn’t necessarily a bad thing. There are benefits to each tool that are undeniable, as there are cons.
I agree wholeheartedly with Pablo’s suggestion that we need a scalable automation framework, but I’d love to see the ability to enforce certain parts of it, like allowing existing orgs to enforce the Sandbox creation of Flows and testing before pushing up to Production. One of the key benefits that Apex offers is the enforcement of basic testing–something I think a lot of businesses would love to see.
I also concur with Pablo’s point that we need to start thinking like software engineers, and that Flow could be enhanced to make this easier. In-app guidance could be switched on and off, or toggled from basic to advanced support, to empower newer Flow creators to learn best practices as they build.
Is Flow a bad option for automation until these things are done properly? I don’t think so. I truly believe that the benefits of the tool, as well as the smaller learning curve, mean businesses can create value using Flow. There are risks, just like there are with any other powerful tool. In other words, with great power comes great responsibility.
Final Thoughts
Pablo, I’d like to thank you for spending the time to pull together such a well-written and thought-provoking read. I think you raised some very important points and have brought awareness to some of the shortcomings of Salesforce Flow.
That being said, I don’t believe Flow is in its early stages as you’ve suggested. Flow has been around in some shape or form for close to 15 years now and is well adopted among Salesforce customers. Salesforce estimated in April 2022 that customers were saving over 100 billion hours every month using Flow, and that number will have only increased since then.
I admire your appreciation for Apex and other programmatic tools. I think there are certainly some benefits that these tools offer over Flow, but as you’ve pointed out, there is continuous improvement being applied to Flow, and it becomes ever more refined with each release.
Which side are you on? Join Pablo and I in an upcoming webinar, Salesforce Automation Throw Down: Apex vs. Flow, where you can share your questions and join the debate.
Comments: