Salesforce Workflow Rules and Process Builder to Flow
Cohash moves Salesforce Workflow Rules and Process Builder automation to Flow. We pull every rule and process from metadata, group them by object, and rebuild them as a few well-ordered record-triggered flows instead of one flow per rule. Time-based actions become scheduled paths, tests cover each object, and old automation is deactivated object by object after the new flows prove out in a sandbox.
- 01Metadata inventory
- 02Design per object
- 03Build and convert
- 04Test
- 05Deploy and deactivate
The story
Told without the client's name or anything that could identify them.
A software company's Salesforce admins had objects where many Process Builder processes and Workflow Rules fired on the same save, and nobody could say what order they ran in. Support for both tools ended on 31 December 2025, and an earlier pass with Migrate to Flow had left a pile of one-to-one flows that nobody reviewed. We pulled every rule, process and Apex trigger from metadata and mapped them per object. Each object now has a small set of before-save and after-save flows with trigger order set on purpose, time-based actions run as scheduled paths, and the old automation was switched off object by object after sandbox comparisons matched.
why it was urgentSince 31 December 2025, Workflow Rules and Process Builder have been out of support. They keep running. But when a release breaks one, Salesforce won't fix the bug or answer the case, and there's nobody to escalate to.
- openOne object has a dozen Process Builder processes and several Workflow Rules firing on the same save.
- recurringNobody can say what fires first on save, so admins leave automation alone.
- blockedPending time-based actions sit in the workflow queue and nobody owns them.
- openSomeone ran Migrate to Flow and got a pile of one-to-one flows that no one has reviewed.
The estate, before and after
Before: Workflow Rules and Process Builder firing on every save
One save could trigger Workflow Rules, several processes, unreviewed converted flows and Apex triggers in an order nobody had mapped. Field updates re-fired triggers, and time-based actions waited in a queue with no owner.
After: a few record-triggered flows per object
Per object, one before-save flow handles field updates and one after-save flow handles related records and actions, in a trigger order someone actually chose. Scheduled paths carry the time-based work, and all of it deploys from source control.
How we run it, phase by phase.
5 phases take you from Workflow Rules and Process Builder to Record-triggered and scheduled flows. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Metadata inventory
Pull every Workflow Rule, field update, email alert, outbound message, time trigger and Process Builder process from metadata. Map them per object, next to the Apex triggers and flows already there.
- phase 02
Design per object
Put field updates in before-save flows, and related records and actions in after-save flows. Choose entry conditions and trigger order on purpose.
- phase 03
Build and convert
Migrate to Flow is fine for simple rules, as long as someone refactors what it produces. Move time-based actions to scheduled paths, and decide what happens to items already sitting in the queue.
- phase 04
Test
Write flow tests and Apex tests that cover each object's save path, including bulk loads and integrations, and compare field values before and after in a full sandbox.
- phase 05
Deploy and deactivate
Deploy flows through source control, deactivate the old rules for that object in the same release, and watch error emails and debug logs for a full business cycle.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Each object has a known save order
Field updates run in before-save flows and related-record work in after-save flows, with entry conditions and trigger order written into the design per object.
- result 02
Time-based work kept running
Renewal reminders and other time-based actions still go out. Pending ones were handled before each rule was deactivated, and new ones run as scheduled paths.
- result 03
Automation ships through source control with tests
Flows deploy from source control with flow and Apex tests that cover each object's save path, including bulk loads and integrations.
- result 04
Results were compared before the switch
We compared before-and-after field values in a full sandbox, then deactivated each object's old rules in the same release as its new flows.
- result 05
Package automation has a vendor plan
Rules that live in managed packages are the package vendor's job. We left them to the vendor's plan and track them in the inventory rather than rebuilding them locally.
Risks we plan for
-
Order of execution changes
Workflow field updates can re-fire triggers in ways flows don't. Moving logic can change results or cause recursion if save order isn't tested.
-
Managed package automation
Don't rebuild rules that live in a managed package. They're the package vendor's, and so is the plan for them.
-
Lost scheduled work
Deactivate a rule with pending time-based actions and you can drop work customers expect, renewal reminders for example. Plan the queue before the switch.
-
Too many flows
One flow per old rule recreates the original tangle in a new tool. Consolidation per object is what makes the result maintainable.
Where AI helps, and where it needs guardrails
Winter '27 turns Agentforce on by default for eligible orgs, and agents often act through flows, so messy automation becomes messy agent behavior. We use an LLM to read each old rule and process and draft a plain-English spec, and an admin checks it before anything is built. Any flow an agent can call should check the running user's permissions and log what it changed.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Automation inventory per object, including Apex and existing flows
yours to keep - design02
Target flow design per object with trigger order
yours to keep - tests03
Flows and tests in source control
yours to keep - report04
Before-and-after field comparison report from a full sandbox
yours to keep - plan05
Deactivation plan with time-based queue handling
yours to keep
Platforms and services on this move
Services involved
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 02Actions
- The replacement for both. Each one is a small JavaScript function you attach to a trigger such as post-login. It carries its own secrets, and other Actions can't read them.in context →
- 03sandbox
- A non-production copy of your system that people test and train on. It eats into your storage just like production does.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Our old rules still run. Why move?
Because nobody will fix them if a release breaks them, and every new automation already has to be a flow. Mixing old and new tools on one object is where most save-order bugs come from.
02Is the Migrate to Flow tool enough?
It's fine for the simple stuff. Because it converts one rule or process at a time, a complex org ends up with a pile of little flows to consolidate and test.
03How long does it take?
It depends on how many objects carry automation, how much is in managed packages, and test coverage. We count rules and processes per object first and estimate from that.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case study6127db5e - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it