If you have administered a Salesforce org for more than a few years, you are probably running automation across three different tools that Salesforce built in three different eras. That is not a sign of a sloppy team. It is what happens when a platform ships a new automation engine roughly once a decade and never forces you to migrate off the old one. The result is that a single object can have a Workflow Rule, a Process Builder process, and a Flow all firing on the same save, and nobody on the team is fully sure what runs first.
That tangle is one of the more common forms of automation debt we untangle on engagements, and it sits inside a larger cleanup story we cover in the Salesforce technical debt field guide. This post zooms into one slice of it: the move from Workflow Rules to Process Builder to Flow, why Salesforce retired its own tools, and the before-save performance change that makes the migration genuinely worth the effort rather than busywork.
Three generations of automation, all still running
Salesforce shipped point-and-click automation in three waves, and each wave was an answer to the limits of the one before it.
Workflow Rules came first and stayed deliberately narrow. A rule watched for a record to meet a condition, then performed a small set of actions: update a field, send an email, fire an outbound message, or create a task. There was no branching beyond the single criteria, no loops, and no way to touch a related record cleanly. It did its one job and did it predictably, which is why a lot of it is still quietly running today.
Process Builder arrived next and felt like a big step up. You could define multiple criteria nodes in order, take different actions per node, create and update related records, and even launch a Flow or call Apex. For a while it was the recommended default for admins who wanted more than a Workflow Rule without writing code.
Flow Builder is the current generation, and it is no longer a sidekick. Flow can do everything the older two could, plus branching, loops, interactive screens for users, create or update or delete records on any object, call Apex, and handle errors with fault paths. It runs on triggers, on schedules, on a button, or inside a screen, which means it covers cases the older tools never could.
The problem was never that any one of these tools was bad. It was that running all three at once turned every save into a guessing game.
Why three tools became a liability
When a record is saved, Salesforce runs a defined sequence of work known as the order of execution: validation, before triggers, the save, after triggers, then the declarative automation, and so on. With one automation tool that order is annoying but learnable. With three, it becomes a real source of bugs.
Picture an Opportunity that has a Workflow Rule updating a field, a Process Builder updating another field based on the first, and a record-triggered Flow doing its own thing. Each tool inserts itself at a different point in the order of execution. A Workflow Rule field update can re-trigger automation. Process Builder runs after the save. The Flow might run before or after depending on how it was configured. Trace a single bad value back through that and you will spend an afternoon on something that should have taken five minutes. Worse, a change in one tool silently breaks an assumption baked into another.
Consolidating to one tool removes that whole class of confusion. There is still an order of execution, but you are reasoning about one engine instead of three overlapping ones, and you can see the entire automation for an object in one place.
Flow is a superset, not a sidegrade
A fair question when any vendor pushes you onto a new tool is whether you are losing anything. With Flow you are not. It is a strict superset of what Workflow Rules and Process Builder could do.
Anything a Workflow Rule did, a record-triggered Flow does. Anything Process Builder did, Flow does and then some. On top of that you get branching with multiple decision outcomes, loops to process collections of records, screen flows that collect input from users, the ability to create, update, or delete records on any object rather than just the triggering one, direct Apex calls, and fault paths so a failure can be caught and handled instead of throwing an unhandled error at the user.
This is also where Salesforce is spending its engineering budget. New automation features land in Flow and nowhere else. Staying on the old tools means freezing yourself out of every improvement that ships from here on.
The performance story: before-save changes everything
Here is the detail that turns this from a tidiness exercise into a measurable win.
Process Builder always ran after-save. When you used it to update a field on the record that triggered it, that update was not part of the original save. Process Builder had to issue a second DML operation to write the record again. So a single user action quietly became two saves: the original commit, then a follow-up update that re-entered the order of execution, burned into your DML governor limits, and opened the door to recursion when automations triggered each other.
Before-save record-triggered flows run before the record is committed. They modify the record in place, in memory, before it hits the database. No second save, no extra DML, no re-trigger. Salesforce has measured these as substantially faster than the equivalent Process Builder, and the reason is structural rather than incremental tuning. You are removing an entire database write from the transaction.
A concrete before and after makes it obvious. Say you want to stamp a normalized email onto a Contact when it is created or updated.
With Process Builder, the shape was roughly:
Trigger: Contact created or edited
Criteria: Email is changed
Action: Update the same Contact record
Email_Normalized__c = LOWER(Email)
--> after-save, a SECOND DML write to the Contact
With a before-save record-triggered Flow, the same intent becomes:
Trigger: Contact created or updated, run BEFORE save
Decision: Email is changed
Assignment: $Record.Email_Normalized__c = LOWER($Record.Email)
--> no extra DML; the value is already on the record being saved
The Flow version sets the field on the record that is already on its way into the database. There is no second trip. On a data load of tens of thousands of Contacts, that difference is the gap between a job that finishes comfortably and one that bumps governor limits and slows the whole org. For high-volume objects, moving same-record field updates into before-save flows is one of the highest-return changes you can make.
A practical migration approach
You do not migrate three generations of automation in a weekend, and you should not try. Treat it as a controlled project.
Start by inventorying what you actually have. List every active Workflow Rule and Process Builder process per object, and note what each one does. Salesforce provides a Migrate to Flow tool in Setup that converts many Workflow Rules and Process Builder processes automatically, and it is a reasonable starting point for the mechanical cases. Just treat its output as a draft to review, not a finished migration.
Group automation by object, not by tool. The goal is one clear automation story per object, so look at everything firing on Opportunity together, decide what the combined behavior should be, and rebuild it as a small number of well-named flows. Same-record field updates belong in a before-save flow. Anything that touches related records, sends email, or calls Apex goes in an after-save flow.
Rebuild and test in a sandbox before you touch production. Recreate the behavior in Flow, run it against realistic data, and confirm the outcomes match the old automation before you deactivate anything. Keep the old automation deactivated rather than deleted at first, so you have a fast rollback if something behaves differently in production.
Remove references before you delete. This is the rule that trips people up. Salesforce will not let you delete a field, a Workflow Rule, or a Process Builder process that something else still depends on. Decouple first, then delete, and always export your data before destructive changes. We walk through how to sequence and prioritize this kind of safe teardown in our guide to tech debt triage and prioritization, because the order you do the work in is what keeps it safe.
Takeaways
Salesforce has blocked creating new Workflow Rules and Process Builder automations and is retiring both, so Flow is the only path that keeps getting new features. Running three tools on one object created an order-of-execution tangle that bred hard-to-trace bugs, and consolidating to Flow removes it. Flow is a superset that adds branching, loops, screens, DML on any record, Apex calls, and error handling. The standout reason to move is performance: before-save record-triggered flows update the record in place before the commit, while Process Builder always paid for a second after-save DML. Migrate deliberately by inventorying what exists, grouping by object, rebuilding and testing in a sandbox, and removing references before deleting anything.
If your org is still carrying a layer of Workflow Rules and Process Builder that nobody wants to touch, that is exactly the kind of automation debt we help teams retire safely without breaking what works. Get in touch to talk through your org, or see how we approach this work on our services page.
