There is a cult following for those who love Salesforce Flow. I say this with confidence because I myself am one of them! Flow was the tool that made me fall in love with the Salesforce platform over a decade ago, and it’s continued to be one of my favorite features in all of Salesforce all these years later.
With that said, I’m not going to pretend I can’t see the beginning of the writing on the wall for Salesforce Flow and tools like it. Don’t get me wrong, I don’t think it’s coming any time soon. But it is coming, as it will for any technology. Here’s why I believe that’s not necessarily a bad thing…
A Nod to the Past
I’d be amiss to begin this conversation without a nod to some recently fallen giants: Process Builder and Workflow Rules. Almost one year ago, in December 2025, Salesforce officially dropped support for both of these tools.
Both were declarative automation tools that served their purpose for many years, and were disrupted by the rapid evolution of Flow Builder. They were retired not because they weren’t helpful, but because something else came along that solved the same problem, but better.
When the retirement was announced, Salesforce encouraged customers to migrate their legacy automation to Salesforce Flow. At times, this wasn’t a clean 1:1 migration. The push was a great opportunity to review what was built in an org, see if it was still relevant in its current state, and rebuild it in a new way where it made sense to do so.
I said in my farewell to these tools that Salesforce Flow will eventually be laid to rest as well. I stand by that statement. Nothing, especially a technology tool, lasts forever. Flow’s time will come.
Two Languages, Two Realms
Today, Flow Builder is the go-to tool for declarative automation in the Salesforce ecosystem. This is where Salesforce Admins and other declarative builders will go for anything that requires some form of logic. When it comes to those who write code (i.e., Salesforce Developers), they’ll work with one of the programming languages that Salesforce supports. This may be Apex for the Salesforce Platform, Visualforce in rare situations, or HTML, CSS, and JavaScript for Lightning Web Components.
This is where the key issue lies. Flow Builder outputs a flow, defined in an XML file. Developers build Apex, Visualforce, HTML, CSS, and JavaScript. While technically a flow is an editable XML file, there will never be an expectation for a developer to open up that XML file and edit it line by line. No, the expectation is always that a flow XML will only really be touched by Flow Builder directly (apart from when it’s being packaged or deployed, of course).
While there are directions from Salesforce on how to use Apex and Salesforce Flow together, they’re still very much two separate things, maintained in two very different ways by two different teams. We’re speaking two different languages here, and that’s always been a problem.
Not to mention how each tool’s output is treated in terms of governance. Apex requires passing a 75% code coverage test successfully before you can deploy it into production. There is no such boundary for a flow, which can be built directly into the production org. For this reason alone, I know many Salesforce customers who will exclusively build in Apex for governance reasons.
The Agents Are Coming! (They’re Already Here)
There’s one topic that I suspect has been notably absent from this article so far, and that’s the topic of AI tooling behaving as a translator. Flow and Apex are two different languages, but agentic AI builders can bring these two worlds together. Admins can communicate with an agent and get it to build a LWC, and developers can point an agent at a flow XML file and get it to make changes without the need to leave their IDE.
Salesforce offers its own first-party agentic AI builder in the form of Agentforce Vibes. It can be used by Salesforce Admins to generate HTML, JavaScript, CSS, or Apex, and explain what any of the existing code actually does. The language barrier between Salesforce Flow users and developers is breaking down in real time, and it’s only just getting started! That’s just Agentforce Vibes – there are many other agentic AI tools out there that can do all of this and more.
Then there’s the new Builder Central that was announced at Dreamforce ‘26. This is a new no-code AI builder that is targeted at Salesforce Admins. While this tool doesn’t output code directly, it does change the dynamic in terms of how Salesforce Admins will build metadata (apps, pages, flows, etc.).
Agentic building is the future for Salesforce Admins and can be used to bridge the gap between developers and admins. The question becomes: Why are Salesforce Admins building flows at all, if they’re able to use an agentic AI tool to write something in a more universal language like Apex? That way, Salesforce Developers can read and write the code at any time, and admins can do so through an agentic translation layer.
While the current state of AI builders doesn’t allow for total reliability yet, it’s definitely where the future is headed. Salesforce is adding more governance into their tools, and with additional features like AgentScript that allow for a more deterministic output for probabilistic features, it’s only a matter of time until AI builders are reliable enough for Salesforce Admins to confidently generate code that developers can also work with.
Salesforce Flow eventually became a tool that solved a problem, but it output something that wasn’t very friendly to developers. Agentic AI tools solve that same problem, but better, because they’re outputting a more standardized output.
Salesforce Flow Isn’t Going Anywhere… Yet
With the agentic revolution in full swing, you’d expect Salesforce to be slowing down its investment in Salesforce Flow, right? Perhaps, but in reality, it’s the opposite. Salesforce’s Flow Builder is being touted as a way of building tools FOR agents to use. Agent Actions can be made up of either Apex or Autolaunched Flows.
In addition, Salesforce’s Flow Builder got a brand new Agentforce for Flow feature set in Spring ‘26. This empowered admins to build new flows using natural language, as opposed to having to build everything from scratch. Summer ‘26 brought a new Create Agent element that allows for the deployment of Agentforce agents directly within a flow.
So, why would Salesforce be investing so heavily into Flow Builder if it also had plans to do away with it? I would take this as a sign that Salesforce DOESN’T have any immediate plans to do away with Salesforce Flow. The company is still heavily investing in it, building new features with each release, and even giving it new tools in the agentic era.
Perhaps a better question is: if Flow Builder is no longer required to build the flows, then what is the real value that Salesforce Flow brings to the table over other offerings with an AI translation layer?
The Final Nail in the Coffin for Salesforce Flow
There’s no denying that eventually Salesforce Flow will be replaced by something newer and better. That’s just the way things go in this space. However, I don’t think we should see the current evolution of AI tooling as the silver bullet that kills it.
I think, somewhere in the future, we’ll see a tool that adds a whole new dimension on top of Apex or other coding languages. Kind of like how Salesforce Flow adds a visual dimension on top of the XML, this future tool will do the same thing for standard languages.
I see it like this: an agentic interface that dynamically displays what the underlying code does. Programmatic languages like Apex are super complex, but newer tools allow for dynamic interfaces to be built upon them. We see this in some shape or form with Salesforce’s new AIforce offerings. Perhaps in the future, it won’t just be the main end-user applications that are dynamically displayed, but also the tools that expand the platform.
When such a tool exists, I think this will be the sign that Salesforce Flow is on its way out. A tool that makes building declaratively as easy as Flow Builder, but does it using standard languages like HTML, CSS, JavaScript, and Apex, will be a game changer. This will become the ultimate translation layer between declarative builders and programmatic developers.
Our Shared Future
With such a tool in existence, I think we’ll enter a whole new paradigm of building together on the Salesforce platform. Salesforce Admins will use this new declarative interface to build their automations and experiences using clicks, but code – no special proprietary output, but clean code. For those hybrid adminelopers (admins who are familiar with coding, or developers who know Salesforce’s declarative tools well), this tool will adapt according to their ways of working.
Developers will see major benefits because everything becomes visible on a single plane. Instead of having to jump between Apex and Record-Triggered Flow to see why something is happening, it will all be visible in Apex. Similarly, they’ll be able to see behind the scenes of a LWC rather than needing to navigate to Flow Builder to see inside a Screen Flow.
Architects will have a much easier time than they do today, having far fewer variables to consider when mapping out solutions. Governance will also be simpler, as everything will be available in a single place, managed together, and won’t require exclusive skills to manage.
Yes, this is a hypothetical future, but I strongly believe it’s one we’ll see very soon. Flow Builder may not be killed off by a better declarative tool, but it may simply be made unnecessary by new declarative building interfaces that sit on top of standard coding languages and frameworks.
Summary
Workflow Rules and Process Builder are dead, replaced by a tool that did it better: Salesforce Flow. Eventually, the day will come when the downsides of Flow Builder outweigh the benefits, or those same benefits can be achieved through a more modern tool. When Salesforce Admins get Flow Builder-like ease of use, but the tool outputs standardized coding files like Apex or LWC, then continuing to leverage a separate declarative tool becomes harder to justify.
Flow Builder may simply be made unnecessary, and a technical burden, simply because another tool does exactly the same thing, but in a more standardized way. That said, I could be totally off-base here. What do you think? Has Flow Builder cemented its place in the Salesforce ecosystem for years to come, or is the writing on the wall beginning to show?
