Platform changes
Workflow Rules end of support: what happens now and what to do
Workflow Rules reached end of support on Dec 31, 2025. What happens now, what still runs, the real risk of waiting, and a plan to move to Flow.
Your Salesforce org was set up years ago. Someone built Workflow Rules to send email alerts and update fields, then added a few Process Builder processes when that was the new tool. That person may have left. You have heard that Workflow Rules reached end of support, and you want to know what happens now, and whether anything is about to break.
The short answer: Workflow Rules and Process Builder reached end of support on December 31, 2025. Your existing rules and processes still run, and you can still activate, deactivate and edit them. What stopped is help: Salesforce no longer provides customer support for them or fixes bugs in them, and it recommends moving that automation to Flow.
What end of support means for Workflow Rules and Process Builder
Salesforce’s own knowledge article is clear on the basics. Active Workflow Rules and processes “continue to run as they do today,” and the only change is that Salesforce “no longer provides customer support or bug fixes for these features.” Salesforce’s help pages for both features say support ended on December 31, 2025, and point new automation to Flow Builder.
So end of support is not a shutdown. Nothing was switched off on January 1. That is why many teams have done nothing, and for an org with two or three simple rules, waiting a little longer is reasonable, as long as you know what you have.
The risk is quieter than a shutdown. If a Salesforce release changes something that an old rule depends on, and the rule starts behaving differently, there is no fix coming. Your options at that point are to work around it or to rebuild it in Flow, under time pressure, while whatever the rule did is not happening.
The real risk is the automation nobody remembers
In many midsize orgs, the problem is not one rule. It is a layer of automation built by different people over several years, with no list of what does what. A distributor in Cedar Rapids might have a rule that stamps a date when an opportunity closes, a process that creates an onboarding task, and an email alert to the warehouse, all on the same object, all built by people who have since moved on.
That layer causes three kinds of trouble:
- Silent failures. An email alert stops firing or a field stops updating, and nobody notices for weeks because nothing shows an error.
- Conflicts with new work. When an admin adds a Flow to an object that still has old rules on it, the two can update the same fields in ways that are hard to trace.
- Knowledge loss. The reason a rule exists often left with the person who built it. Deleting it feels risky, so it stays forever.
If any of those sound familiar, the end of support is a useful prompt to clean up, whether or not anything has broken yet.
How to take an inventory before you migrate
Start with a list, not a migration. Setup lists your Workflow Rules and processes and shows which are active. Copy that list into a spreadsheet an admin can work from, with these columns. In a small org it is a short job; in an older org it is the most useful part of the whole migration.
| Column | What to record |
|---|---|
| Object | Which record type the rule runs on, such as Opportunity or Case |
| Active | Whether it is switched on today |
| What it does | Field update, email alert, task, outbound message, or a call to Apex or another flow |
| Who relies on it | The team or report that would notice if it stopped |
| Last changed | When it was last edited, and by whom if known |
| Decision | Move to Flow, merge with another automation, or retire |
Inactive rules are usually the easiest win. If something has been switched off for a year and nobody missed it, document it and plan to remove it rather than migrate it.
What to move to Flow first
Order the active automation by what breaks if it stops. In practice that means:
- Anything that touches money or compliance. Discount approvals, invoice flags, regulatory dates. A credit union in Lincoln or an insurance agency in the Kansas City metro would likely have a few of these, and they come first.
- Anything customers see. Email alerts to customers, case routing, service notifications.
- Objects with both old rules and new Flows. Consolidating these removes the conflicts described above.
- Everything else. Internal reminders and convenience field updates can follow in batches.
Salesforce provides a Migrate to Flow tool in Setup that converts eligible Workflow Rules and processes into flows. It helps, but it does not handle everything. Salesforce’s own Trailhead project on the tool lists features it cannot convert, such as workflow task actions, and notes that some processes migrate only partly. Treat every result as a draft: review it, test it in a sandbox with realistic records, then activate the new flow and deactivate the old rule together, so the same work does not run twice.
How to scope a migration for a midsize company
For an org with a handful of simple rules, a capable admin can often inventory, migrate and test alongside normal work. For a manufacturer in Wichita with years of layered automation across sales, service and an ERP integration, it is better run as a small project with a clear list, a sandbox, a test plan for each object and a release date.
Timing matters too. If your company in Nebraska, Iowa, Kansas or Colorado sets next year’s budget in the fall, a migration is easier to fund as a planned line item than as an emergency after something breaks. Teams with a seasonal rush, such as harvest or the construction season, can plan the work for their slower months.
If you would rather have someone outside the team size the work, our two to three week diagnostic maps how data moves between your systems and hands you a costed roadmap that you own, with no obligation to have us build any of it.
Common questions
Will my Workflow Rules stop working?
Not because of the end of support itself. Salesforce says existing rules and processes continue to run. The change is that bugs in them are no longer fixed and Salesforce support will not help with them.
Can I still create new Workflow Rules or processes?
Salesforce says to build all new automation in Flow, so treat Workflow Rules and Process Builder as closed to new work. You can still edit, activate and deactivate the ones you already have.
Do we need a consultant to migrate to Flow?
Not always. A small org with a few rules and an admin who knows Flow can do it in house. Outside help makes sense when nobody knows what the old automation does, when it touches billing or an integration, or when the admin has no time for a project on top of daily support.