Key takeaways
- Salesforce ended support for Workflow Rules and Process Builder after 31 December 2025, so they no longer receive bug fixes or support.
- Flow is now Salesforce’s main tool for declarative automation.
- Do not convert automation one-to-one. Audit it, remove what is unused, then consolidate into well-designed Flows.
- Test in a sandbox with realistic data volumes before deactivating the old automation.
Why this migration matters now
Salesforce announced that Workflow Rules and Process Builder would no longer be supported after 31 December 2025. In practice, that means existing automation built with these tools no longer receives Salesforce support or bug fixes. If a process breaks or behaves unexpectedly, you are on your own.
Many UAE orgs that went live several years ago still run a mix of Workflow Rules, Process Builders, Flows and Apex triggers on the same objects. That mix makes the order of execution hard to predict and changes risky. Moving to Flow is a chance to make your automation simpler and easier to maintain.
What Flow can do
- Record-triggered Flows: run when a record is created, updated or deleted, before or after save.
- Scheduled Flows: run on a schedule, for example nightly reminders or renewals.
- Screen Flows: guided forms for users, such as onboarding or approval requests.
- Autolaunched Flows: reusable logic called from other Flows, Apex, APIs or Agentforce actions.
Flow also supports error handling paths, subflows and debugging tools that the older tools lacked. And because Agentforce actions can be built from Flows, a clean Flow layer prepares your org for AI agents too.
A five-step migration approach
1. Inventory every automation
List all active Workflow Rules, Process Builders, Flows and Apex triggers by object. Record what each does, when it fires, and who owns the business rule. Salesforce’s setup pages and the Migrate to Flow tool help identify what exists.
2. Remove what is no longer needed
Older orgs often contain automation for teams, products or fields that no longer exist. Confirm with business owners and retire anything unused. Every rule removed is one less thing to migrate and test.
3. Redesign, do not just convert
The Migrate to Flow tool can convert many Workflow Rules and some Process Builders, but a one-to-one conversion keeps old problems. A better pattern is:
- One before-save Flow per object for fast field updates
- One or a small number of after-save Flows per object for related records, emails and integrations
- Clear entry criteria so each Flow runs only when needed
- Subflows for logic used in several places
4. Test with realistic data
Test in a full or partial copy sandbox with realistic data. Include bulk updates, such as a data load of several thousand records, because automation that works for one record can hit governor limits in bulk.
5. Deploy and switch over carefully
Deploy the new Flows inactive, then activate them and deactivate the old automation in the same release window. Monitor errors closely for the first weeks and keep a rollback plan.
Workflow Rule and Process Builder actions in Flow
| Old action | Flow equivalent |
|---|---|
| Field update on the same record | Before-save record-triggered Flow (fastest option) |
| Email alert | Send Email Alert action in an after-save Flow |
| Create or update related records | After-save Flow with Create or Update Records elements |
| Time-based workflow | Scheduled paths in a record-triggered Flow |
| Outbound message | Outbound message action, or a platform event or HTTP callout |
| Invoke another process | Subflow |
When to use Apex instead
Flow handles most business automation, but Apex is still the better choice for very high-volume processing, complex calculations or logic that must run asynchronously in batches. In one of our case studies, the project combined a Flow migration with an Apex Batch class for bulk lead conversion, because the volume was too high for a single transaction.
Common pitfalls
- Converting everything without checking whether it is still used
- Creating many small Flows on the same object with overlapping entry criteria
- Forgetting fault paths, so users see generic errors
- Testing only single-record edits, not bulk updates or integrations
- Leaving old rules active alongside new Flows, which causes duplicate updates
Need help with the migration?
A migration is a good fit for a short assessment followed by phased delivery, object by object. Our Salesforce managed services team can audit your current automation and deliver the migration alongside day-to-day support. If you need extra build capacity, you can hire a Salesforce developer or hire a Salesforce admin.
Frequently asked questions
Will my Workflow Rules and Process Builders stop working?
Salesforce ended support for them after 31 December 2025, which means no support or bug fixes. Relying on unsupported automation is a risk, so plan the migration rather than waiting for something to break.
Can the Migrate to Flow tool do everything automatically?
It converts many Workflow Rules and some Process Builders, but results should be reviewed and consolidated. A straight conversion can keep inefficient designs.
How long does a Flow migration take?
It depends on how much automation you have and how complex it is. Small orgs can migrate in a few weeks; orgs with many objects and integrations usually migrate in phases over a few months.
Should we migrate to Flow or Apex?
Use Flow for most business automation because admins can maintain it. Use Apex for high-volume processing, complex logic or performance-sensitive work.
Still running Workflow Rules or Process Builder?
We can audit your automation and plan a safe, phased migration to Flow.
Related articles
Sources