Workflow Rules and Process Builder to Flow: A Migration Plan for Unsupported Automation

Workflow Rules and Process Builder to Flow migration is now an important maintenance task for Salesforce teams. Salesforce ended support for both legacy tools on December 31, 2025, but existing rules and processes can still run. That means an old Opportunity alert or field update may continue working without receiving future bug fixes. Before replacing it, your team needs to understand what triggers it, which records it changes, and whether other automation depends on it. A successful migration starts with documenting those connections instead of converting rules without checking their behavior.

In this guide, we explain how to inventory legacy automation, use the Migrate to Flow tool, rebuild unsupported logic, and test new Flows before activation. We also cover execution order, scheduled actions, rollback planning, and ongoing maintenance. You will learn where the migration tool can save time and when a manual rebuild makes more sense. If your organization needs support with complex automation, our Salesforce automation services can help assess, rebuild, and test the affected processes.

TL;DR

Unsupported Automation Still Runs, With No Safety Net

Salesforce says Workflow Rules and Process Builder processes keep running, but they get no support and no bug fixes. That makes every old rule a quiet liability. The longer you wait, the more business logic sits on tools nobody can call Salesforce about.

The Migrate to Flow Tool Is a Starting Point

The tool converts one rule or process at a time and skips several patterns, including related-record criteria and some scheduled actions. Treat its output as a first draft. Test order of execution, recursion and validation behavior before you activate anything.

Inventory, Convert, Test, Cut Over, Then Govern

A safe migration moves in five steps. List every active rule, convert the simple ones with the tool, rebuild the complex ones by hand, test in a sandbox, then switch over one object at a time. After that, set rules so the mess doesn’t return.

What End of Support Means for Your Org Today

Salesforce says Workflow Rules and Process Builder processes will continue running as before, so nothing broke on January 1. That is reassuring, but it can also create false confidence. “Unsupported” means Salesforce will no longer fix bugs or provide help when this older automation fails after a platform release. The company recommends moving the logic to Flow Builder as soon as possible and warns that migration may require planning, testing, and time. You can follow the change on Salesforce’s product and feature retirements page and review the official end of support notice for details. The practical takeaway is simple: existing automation may keep running, but defects will not be fixed, and all new business logic should be built in Flow.

Be cautious with advice in older articles because many were written before the support deadline and still describe the change as upcoming. Salesforce’s own pages may also use different wording about how Workflow Rules and Process Builder are treated. Check what your org allows, review the official help article, and do not rely on a blog summary. The risk becomes clearer during administration. A new field, changed picklist value, validation rule, or another Flow touching the same object can interact with old automation unexpectedly. Without Salesforce support, your administrator must trace the failure through debug logs and dependencies alone. That risk grows with every release, so migration should be treated as planned maintenance rather than postponed until something eventually breaks.

Inventory Every Workflow Rule and Process Before You Touch Anything

You cannot plan a migration until you know what needs to move. In Setup, open Workflow Rules and Process Builder under Process Automation, check the active status column, as Salesforce recommends in its end of support guidance. Focus on active items first, but record inactive ones so your team can review or remove them later. For every active rule or process, document the object it runs on, whether it starts when a record is created, edited, or both, and the criteria that control it. List every action, including field updates, email alerts, tasks, outbound messages, and Apex calls. Finally, identify the people, reports, systems, and business processes that depend on the automation, because those dependencies often reveal its real purpose.

Next, sort the inventory into three groups: retire, convert as-is, and redesign. Retire automation that supports work nobody needs, convert logic that remains correct, and redesign anything tangled, duplicated, or outdated. Many organizations discover that the retirement group is larger than expected because years of changes leave behind field updates and alerts that no longer serve a purpose. Before making that decision, speak with affected teams. Ask sales who receives each alert and ask finance what happens after a field changes. A rule that appears unused may still feed a weekly report or an external process. For example, changing the sender or subject line of a finance email could break an inbox rule, even when Salesforce reports no migration error.

Also review the automation surrounding each item. Apex triggers, scheduled jobs, validation rules, integrations, and other Flows may read or change the same records. Timing matters because a trigger that expects a field update at one point may behave differently when a new Flow changes it earlier or later. Watch for automation installed by managed packages. Those components belong to the package vendor, so ask the vendor about its migration plan before editing them. If you want help uncovering these connections, our free Salesforce audit evaluates automation and provides a fix plan. You can read our guide explaining how Salesforce partners prevent technical debt and security issues. A complete dependency map makes migration decisions safer, clearer, and easier to test.

How Flow Differs From the Tools It Replaces

• Save timing matters: Flow can run at different points during a record save than Process Builder did. That timing difference can change field values, trigger other automation, and affect the final outcome.
• Before-save flows update the triggering record: Salesforce calls these Fast Field Updates. They run before the record is written and work well for changing fields on the same record.
• After-save flows handle related actions: They run after the record is saved and can update related records, create new records, send emails, call Apex, or start other automation.
• Choose the flow type by action: A Workflow Rule that updates its own record usually becomes a before-save flow. Processes involving related records or notifications usually require an after-save flow.
• Flow can improve performance: Salesforce states that Fast Field Updates can run almost ten times faster than Workflow Rules and Process Builder. Test performance in your org before relying on that figure.
• Entry conditions reduce unnecessary runs: Record-triggered flows can start only when specified conditions are met. This prevents automation from running after every save and reduces avoidable processing.
• Testing and execution order are clearer: Flow Builder supports step-by-step debugging with test data. Flow Trigger Explorer also lets administrators assign priorities and control the order of record-triggered flows.
• Use the right automation tool: Salesforce’s Trailhead migration project explains these changes. Our Agentforce, Flow, and Apex guide explains which option fits different requirements.

What the Migrate to Flow Tool Can and Cannot Convert

Salesforce ships a Migrate to Flow tool in Setup. It converts one workflow rule or process into a flow, and it doesn’t change or deactivate the original until you do. Its limits are documented in Salesforce’s tool considerations.

How the Migrate to Flow Tool Works

Salesforce includes the Migrate to Flow tool in Setup to convert one Workflow Rule or Process Builder process. The tool creates a new flow but does not edit, deactivate, or delete the original automation. This allows administrators to review the converted logic and test its behavior before switching anything off. However, conversion does not always produce a finished flow. Some actions require additional configuration, while unsupported logic may need to be rebuilt manually. Salesforce documents the limits on its Migrate to Flow tool considerations page. Review that page before starting each migration batch because supported features can change between releases.

What Converts From Process Builder

For Process Builder, the tool supports only record-triggered processes. It can convert record updates, record creation, invoked flows, invoked Apex actions, and email alerts without setup. Other actions convert but need configuration before activation. These include Post to Chatter, Quick Actions, Submit for Approval, Send Custom Notification, Live Message Notification, and Send Surveys. The tool does not support custom event processes, custom invocable processes, criteria using related-record field traversals, or formulas containing cross-object references. Processes that use recursion are not fully supported either. Administrators should inspect each converted element and confirm that the resulting flow matches the original process behavior.

What Converts From Workflow Rules

For Workflow Rules, the tool can convert field-based criteria, field updates, email alerts, outbound messages, and time-dependent actions. A rule containing only field updates usually becomes a before-save flow. However, rules with no defined actions, criteria using global variables, related-record fields, or record types will not convert. Unsupported operators include “does not contain,” “includes,” “excludes,” and “within.” The tool rejects formulas using HOUR, MINUTE, SECOND, TIMENOW, TIMEVALUE, ISCLONE, or $RecordType. Task actions, relative date values, and multiple currencies are unsupported as well. If a Workflow Rule uses any of these features, plan to rebuild and test it manually in Flow.

Review Every Conversion Result

Every migration run produces one of three results: converted, partly converted with items requiring review, or not convertible. A partial conversion is not a finished flow because an administrator must complete the configuration and verify each action. Unsupported rules and processes may not appear in the tool’s list at all. If an item seems missing, compare it with your automation inventory and prepare for a manual rebuild. Test every new flow with data before activation, confirm its timing and dependencies, and keep the original automation active until testing is complete. Always recheck Salesforce’s considerations page before beginning another conversion batch.

Order of Execution: The Quiet Source of Migration Bugs

1. List All Automation on the Object
   Before migrating an object, document every flow, Apex trigger, validation rule, Workflow Rule, and Process Builder process that runs on it. A flow may work correctly alone but produce different results when other automation runs during the same save.
   
   
2. Map the Current Order of Execution
   Salesforce runs before-save flows at Step 3, Workflow Rules at Step 11, Process Builder processes and workflow-launched flows at Step 13, and after-save flows at Step 14. Step 13 automation does not run in a guaranteed order. Review the complete sequence in Salesforce’s order of execution reference.
   
   
3. Compare the Old and New Timing
   A workflow field update runs at Step 11, after before triggers and validation. If you replace it with a before-save flow, the update moves to Step 3. Triggers and validation rules that previously received the old field value may now receive the updated value.
   
   
4. Check for a Second Trigger Pass
   A workflow field update saves the record again. System validations rerun, and before and after update triggers fire a second time. However, custom validation rules, flows, duplicate rules, and Process Builder processes do not rerun. Moving the update into a before-save flow removes that second trigger pass.
   
   
5. Set the New Flow Priority
   Process Builder processes previously ran together at Step 13 without a guaranteed sequence. Record-triggered flows can now follow a defined order. Use Flow Trigger Explorer to assign priorities and document which flow should run first, second, and later.
   
   
6. Walk Through and Test the Complete Save
   Review a full record save step by step before activating the replacement flow. Check which values each trigger, validation rule, and flow receives at every stage. This short review can identify timing conflicts and hidden dependencies that isolated flow tests may miss.

Choosing Between the Tool and a Rebuild

Use the table below to decide whether each Workflow Rule or Process Builder process should be converted with the tool, rebuilt manually, or improved after conversion.

A Worked Example: Converting an Opportunity Rule

Consider a sales team that uses a Workflow Rule to mark an Opportunity as ready for handoff when its stage changes to Closed Won. The rule updates a custom checkbox called Handoff_Ready__c. It looks simple, but the team must confirm how the field update affects validation rules, Apex triggers, and other automations before replacing it. Here’s how an administrator could migrate this example to Flow.

Step 1: Review the Existing Workflow Rule

Start by documenting the rule’s object, evaluation criteria, and field update. In this example, the rule checks whether an Opportunity has reached Closed Won and whether the handoff checkbox is still unchecked. When both conditions are met, it sets the checkbox to true. Before changing anything, confirm whether another automation reads that field or depends on the original update timing.

Step 2: Build the Replacement Flow

Create a record-triggered flow on the Opportunity object that runs when records are created or updated. Set the entry conditions to match the original rule, then choose Fast Field Updates because the action changes only the triggering record. Use an Assignment element to set the handoff checkbox to true. Configure the conditions so the update happens only when required, rather than on every unrelated Opportunity edit.

Step 3: Test the New Behavior

Test the flow in a sandbox with an Opportunity moving to Closed Won, one already marked for handoff, and another that remains in an earlier stage. Confirm that the checkbox changes only when expected. Review how the new before-save timing affects Apex triggers, validation rules, and other flows. Repeat the test with multiple records to check for bulk-processing errors.

Step 4: Prepare the Cutover

Compare the results of the old Workflow Rule and the new Flow before deploying the replacement. Record the expected field values, confirm that connected automation still works, and prepare a rollback procedure. During the approved cutover window, switch to the new Flow and check the results with representative production records.

This example shows why even a simple field update needs testing. The original Workflow Rule and the replacement before-save Flow can produce the same final field value while behaving differently during the record-save sequence.

Handling Scheduled Actions, Recursion and Callouts

Three patterns need extra care because they behave differently in Flow.

• Scheduled actions. Salesforce says the tool migrates scheduled actions only when you select the single criterion that owns them. Migrated actions become scheduled paths named ScheduledPath followed by a number. Rename them straight away, because the generic names are hard to read. Then test timing by confirming the path fires when you expect after the trigger.
  
  
• Recursion. Process Builder could re-evaluate a record several times in one transaction. Trailhead says processes that evaluated a record up to six times evaluate it only once after migration. If your logic depended on a second or third pass, such as a field set by one criterion feeding another, the migrated flow may stop short. Rebuild that chain on purpose, with the steps in a clear order.
  
  
• Callouts and waits. Invoke flow actions become subflow elements, which run in the same transaction as the parent flow. Trailhead says invoke flow actions that involve external callouts, external actions or pauses should be redesigned to use an asynchronous path. A callout inside a synchronous flow can slow a save or fail it.

A simple test helps here. For every migrated automation, ask whether it does anything slow: a callout, a wait or a large batch of record changes. If yes, move that work to an asynchronous path.Bulk behavior deserves its own check. A rule that works for one record can fail when a data load touches thousands. Test with a realistic volume in a sandbox, and watch for governor limit errors in the debug log.

Testing Before You Switch Anything Off

Always build and test flows in a sandbox or scratch org, never with live production data. Create a test plan for each object and run it twice: once with the old automation and once with the new flow. Results should match unless the migration includes an intentional change. Cover the normal path by creating and editing records, then confirm field values, emails, tasks, and related records. Test blank fields, null values, unusual picklist options, inactive record owners, and edge cases. Repeat the tests as both a standard user and an administrator because execution context and permissions can change flow behavior. Load several hundred records and confirm that triggers, validation rules, integrations, and neighboring automation still work without errors or delays.

Use Flow Builder’s debug tool to inspect steps, and use record-triggered flow tests if your Salesforce release supports them. Check email alerts because leaving the original rule active while testing the replacement flow can send duplicate messages. Bring users into acceptance testing and compare the old and new results side by side. The person who owns the process may notice details that an administrator would not. Test failures intentionally by removing a permission, omitting a required value, or sending an unexpected record into the flow. Confirm that failures create visible errors or alerts instead of disappearing silently. Keep a short test log for each object so auditors and future administrators can see what was tested, what passed, and what changed.

Cutover Sequence and Rollback

A successful migration needs more than a working Flow. Administrators must also control the switch between old and new automation so records are not updated twice, notifications are not duplicated, and scheduled actions are not missed. Complete the testing and choose an approved maintenance window before making changes in production.

Follow these six steps for each object or connected group of automations.

1. Prepare the deployment: Deploy and review the replacement Flows, confirm their entry conditions, and keep them inactive until cutover. Record the existing automation settings and approved Flow versions.
2. Check scheduled actions: Review pending Workflow Rule and Process Builder actions before switching. Deactivating a Workflow Rule does not automatically cancel every pending action. For Process Builder migrations with scheduled actions, confirm that the migration approach preserves or accounts for the existing queue.
3. Choose a cutover window: Select a low-activity period and coordinate with affected users. Assign responsibility for activation, validation, monitoring, and rollback.
4. Switch the automation: Deactivate the legacy rule or process and activate the replacement Flow in a controlled sequence. Keep the transition brief and verify that new transactions do not trigger duplicate or missing actions.
5. Validate production behavior: Test representative records and check field updates, email alerts, related records, scheduled paths, and connected integrations. Compare the results with your approved test cases.
6. Monitor after deployment: Review Flow errors, failed interviews, unexpected record changes, and business feedback. Continue monitoring long enough to cover important scheduled actions and recurring processes.

What to Do if the New Flow Fails

Prepare the rollback procedure before cutover. If the new automation causes errors, stop it and determine whether the previous Workflow Rule or Process Builder process can be safely reactivated. Salesforce currently allows administrators to reactivate existing legacy automation, although it no longer provides support or bug fixes for those features.

Before restoring the old process, inspect pending scheduled actions and records already updated by the new Flow. Reactivating old automation without checking those results can create duplicate notifications or repeat business actions.

Keep the original configuration and deployment records until the migration has passed its agreed monitoring period. Once the team confirms that the replacement works, retire the old automation according to the organization’s change-management policy.

A Phased Timeline for Migrating Object by Object

Four Phases of Salesforce Flow Migration

Every Salesforce org has different automation requirements, so the migration schedule depends on the number of active rules, their complexity, and the testing involved. Instead of moving every process at once, organize the work into four phases. Each phase should have a clear outcome before the next begins.

Phase 1: Inventory and Cleanup

Review all active Workflow Rules and Process Builder processes, document their actions, and identify dependencies. Separate outdated automation from processes that still support business operations. The outcome should be an approved migration inventory showing which rules to retire, convert, or rebuild.

Phase 2: Start With a Low-Risk Pilot

Choose an object with relatively few rules and limited dependencies. Convert its automation, run tests in a sandbox, and complete a controlled cutover. Record the time spent on development, testing, and deployment. Use those results to improve the process before migrating more critical objects.

Phase 3: Migrate Core Business Objects

Move to objects such as Lead, Account, Opportunity, and Case based on business priority and technical risk. Review overlapping automation, execution order, scheduled actions, and integrations before migrating each object. Use the same testing and approval process established during the pilot.

Phase 4: Monitoring and Handover

Confirm that the replacement Flows work correctly, document their owners and dependencies, and review outstanding errors or scheduled actions. Remove legacy automation only after the agreed monitoring period. Give administrators the information they need to maintain the new Flows without relying on the migration team.

The duration of each phase depends on the inventory and business requirements. A smaller org may complete the work quickly, while an environment with extensive integrations and custom Apex may need a longer testing and deployment schedule.

Where Apex and Developers Fit

Anything that needs complex logic, heavy data volume or precise control of timing may work better as Apex. If a flow has grown to dozens of elements with nested loops, a developer can usually do it more clearly and test it more reliably.The reverse is also true. Teams sometimes keep old Apex that does what a simple flow now handles, because nobody wants to rewrite it. Migration is a fair time to ask whether each piece sits in the right place.

Apex also has a role in the migration itself. If a process calls an Apex action, that action keeps working in the converted flow, and the tool supports the invoke Apex action. Developers can confirm the code handles bulk updates and doesn’t assume it runs at the old moment in the save.When your team doesn’t have the capacity, you can hire a Salesforce developer for the pieces that need code while your admins handle the clicks. Splitting the work this way keeps flows readable and Apex testable.

Governing Flow After the Migration

A migration that ends at cutover can leave the same maintenance problems inside Flow. Establish clear standards so administrators know what each Flow does, who maintains it, and how to respond when something fails. Salesforce’s Planning Your Switch to Flow Builder guidance provides additional recommendations for managing the transition.

• Naming standards: Use consistent names that identify the object, trigger type, and purpose of each Flow.
• Clear ownership: Assign responsibility for reviewing new automation, approving changes, and preventing overlapping processes.
• Documentation: Record each Flow’s purpose, entry conditions, dependencies, and expected business outcome.
• Error handling: Add appropriate fault handling and make sure administrators receive useful failure notifications.
• Version control: Keep approved versions, document changes, and remove outdated configurations after testing and rollback requirements are satisfied.
• Regular reviews: Check active Flows, failed interviews, execution performance, and automation dependencies every quarter.

These standards help teams maintain the new automation after the migration project ends. If your organization needs support beyond the initial cutover, our Salesforce implementation services cover automation changes, deployment, integration, and ongoing platform improvements.

Conclusion

Moving Workflow Rules and Process Builder to Flow is more than replacing old automation with a newer tool. Each rule has conditions, actions, and dependencies that must continue working after migration. Start with a manageable pilot, test the results, and move to more complex objects once your team has a reliable process.

Salesforce Flow gives administrators greater control over automation, but the work does not end at activation. Keep clear documentation, review errors, assign ownership, and check performance after deployment. A migration succeeds when the new automation works correctly and remains easy to maintain.

100+ Salesforce Certifications Supporting Your Migration

At VALiNTRY360, our Salesforce team brings more than 100 Salesforce certifications across the practice, with expertise in administration, development, automation, and integration. We can review your existing Workflow Rules and Process Builder processes, build replacement Flows, test dependencies, and support the production cutover.

If your organization is still running unsupported automation, we can help you understand what needs to move and prepare a realistic migration plan. Connect with our Salesforce team to discuss your requirements.

FAQs

Frequently Asked Questions

1. Is Salesforce Discontinuing Workflow Rules and Process Builder?

Yes. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Both tools are now considered legacy automation. Salesforce recommends moving existing automation to Flow Builder, which receives ongoing support and development.

2. Will Existing Workflow Rules and Process Builder Processes Stop Working?

No. Existing Workflow Rules and Process Builder processes can continue running after the support deadline. However, Salesforce no longer provides bug fixes or customer support for these tools. Organizations should plan a migration rather than wait for an automation failure.

3. Can I Still Edit or Reactivate Workflow Rules in Salesforce?

Yes. Salesforce still allows administrators to edit, activate, and deactivate existing Workflow Rules and Process Builder processes. However, both tools remain unsupported. Salesforce recommends using Flow Builder for new automation instead of continuing to build on legacy features.

4. What Is the Difference Between Workflow Rules, Process Builder, and Flow Builder?

Workflow Rules handle basic conditional actions, while Process Builder supports more involved automation across records and actions. Flow Builder offers broader control over record updates, decisions, scheduled actions, and integrations. Salesforce now recommends Flow Builder as its primary tool for low-code process automation.

5. How Do I Migrate Workflow Rules to Flow in Salesforce?

Open Setup, search for Migrate to Flow, and select the Workflow Rule you want to convert. Review the generated Flow and test it in a sandbox. Once the replacement works correctly, activate it and deactivate the original rule through a controlled cutover.

6. Can Process Builder Be Automatically Converted to Flow?

Yes, Salesforce’s Migrate to Flow tool can convert supported record-triggered Process Builder processes. Some actions migrate automatically, while others need additional configuration. Processes with unsupported criteria or actions may require manual rebuilding. Always review the generated Flow before activating it.

7. What Cannot Be Converted Using the Migrate to Flow Tool?

The tool cannot automatically convert every Workflow Rule or Process Builder process. Limitations include certain related-record criteria, unsupported formulas, task actions, and some recursive behavior. Custom event and custom invocable processes are also unsupported. Check Salesforce’s current tool considerations before deciding whether to convert or rebuild.

8. Can Multiple Workflow Rules Be Combined Into One Salesforce Flow?

Yes. Several Workflow Rules operating on the same object can sometimes be consolidated into one organized Flow. However, combining them is not always the best choice. Review their entry conditions, execution timing, and dependencies before merging logic to avoid unexpected record updates.

9. Should I Use a Before-Save or After-Save Flow When Migrating?

Use a before-save Flow when the automation only updates fields on the record that triggered it. Use an after-save Flow for actions such as updating related records or sending notifications. The correct choice depends on the original automation’s purpose and execution requirements.

10. What Happens to Time-Based Workflow Actions During Migration?

Supported time-based actions can become scheduled paths in Flow Builder. However, pending actions require careful review because their behavior depends on the original automation and migration method. For Process Builder, migrating within the same Salesforce org is important when handling previously queued scheduled actions.

11. Does Migrating to Flow Change Salesforce’s Order of Execution?

It can. Workflow Rules, Process Builder processes, and record-triggered Flows execute at different points during a record save. Moving an action into a before-save or after-save Flow may change how Apex triggers, validation rules, and other automation behave. Test the complete record-save sequence before deployment.

12. How Do I Test Migrated Salesforce Flows Before Deployment?

Test the replacement Flows in a sandbox using sample records. Check normal scenarios, missing values, user permissions, scheduled actions, and bulk updates. Use Flow Builder’s testing and debugging features, then compare the results with the original automation before activating the new Flow in production.

13. How Can I Prevent Duplicate Emails and Record Updates During Migration?

Avoid running the old automation and its replacement together on the same transactions. Review pending actions, test the new Flow, and coordinate activation and deactivation during an approved cutover window. Check email alerts and record changes immediately afterward to confirm that actions are not running twice.

14. Can I Roll Back to Workflow Rules or Process Builder if a Flow Fails?

Yes. Existing Workflow Rules and Process Builder processes can currently be reactivated. Before doing so, check whether the new Flow has already updated records or scheduled actions. Restoring old automation without reviewing those changes can cause duplicate work. Remember that the legacy tools remain unsupported.

15. How Long Does It Take to Migrate Workflow Rules and Process Builder to Flow?

The timeline depends on the number of active rules, their complexity, integrations, and testing requirements. Simple field updates may take less effort than processes with recursion or scheduled actions. Start with an automation inventory and a small pilot to estimate the remaining migration work accurately.