Salesforce is accelerating the retirement of Workflow Rules and Process Builder, making Flow the singular, powerful automation tool for the platform’s future. For Salesforce Administrators, this is the time for a critical, organized migration.
This guide provides a professional, step-by-step pathway to successfully move your existing automations to Flow, ensuring your org remains fast, clean, and future-proof.
Phase 1: The Migration Mindset and Strategy
Before clicking a single button in Flow Builder, you need a smart, consolidated strategy. The goal isn’t a one-to-one recreation; it’s consolidation and optimization.
1. The Core Best Practice: One Record-Triggered Flow Per Object
In the past, you might have had ten Workflow Rules and three Process Builders running on the Account object. This is inefficient.
The new best practice is to aim for one primary Record-Triggered Flow per object (e.g., one flow for the Account object, one for the Opportunity object). You will use the Flow’s powerful Decision elements to handle all the branching logic that was previously spread across multiple separate automations.
2. The Golden Rule: Build in Sandbox, Test Rigorously
Never make automation changes directly in Production. Always perform the full migration, testing, and deactivation process in a Sandbox environment first.
3. Identify and Prioritize Your Automation
Use a simple spreadsheet to audit your WFRs and PBs. Focus first on simple automations, then move to complex ones.
| Automation Name | Object | Type | Functionality | Complexity | New Flow Context | Priority |
Update_Opp_Owner | Opportunity | WFR | Update owner if stage is ‘Closed Lost’ | Low | After Save (DML) | High |
Complex_Lead_Conversion | Lead | PB | Create tasks, update related records | Medium | After Save (DML/Related) | Medium |
Phase 2: Step-by-Step Migration of Workflow Rules
Workflow Rules (WFRs) are generally the easiest to migrate, especially those with only simple field updates or email alerts. Salesforce has provided a dedicated tool for this.
Step 1: Use the Migrate to Flow Tool (Recommended for Simple WFRs)
For WFRs that perform basic field updates, email alerts, or tasks, the built-in tool is your friend.
- Navigate to Setup and search for Migrate to Flow.
- Select the Workflow Rule you want to migrate.
- Click the Migrate to Flow button.
The tool automatically converts the WFR’s criteria, immediate actions, and time-dependent actions into a new, inactive Record-Triggered Flow.
Step 2: Review and Optimize the Generated Flow
The automatically generated Flow is usually a good starting point, but it might not be optimized.
- Check the Trigger: The tool often defaults to an After-Save Flow. If your WFR only does a field update on the same record (which most do), you should change the Flow to Before-Save.
- Goal: Before-Save is 10x faster because it updates the record in memory before it’s saved to the database, avoiding a separate DML operation.
- Consolidate Logic: If you’re moving multiple WFRs for the same object, copy the logic from the new flow’s Decision and Update Record elements and paste them into your single, main object Flow.
Simple Drawing Concept: WFR:
(Entry Criteria) -> (Immediate Action)Flow (Optimized):(Start Element: Before Save) -> (Decision: WFR Criteria?) -> (Assignment: Field = Value)
Step 3: Handle Time-Dependent Actions (Scheduled Paths)
Flows handle WFR’s time-dependent actions beautifully using Scheduled Paths.
- In your Flow, when defining the action elements, use the Add Scheduled Paths option.
- You can set the schedule based on a specific date field or elapsed time (e.g., 5 days after
Opportunity Close Date). This directly replaces the functionality of a time-dependent workflow action.
Step 4: Activate and Deactivate
- Thoroughly test the new Flow in your Sandbox.
- Once confirmed, Deactivate the original Workflow Rule.
- Activate the new Flow.
This revised blog post focuses heavily on the step-by-step migration process for both Workflow Rules (WFRs) and Process Builder (PBs), maintaining a professional yet simple tone with clear structure and drawing concepts.
The Complete Guide to Migrating Salesforce Workflow Rules and Process Builder to Flow
Salesforce is accelerating the retirement of Workflow Rules and Process Builder, making Flow the singular, powerful automation tool for the platform’s future. For Salesforce Administrators, this is the time for a critical, organized migration.
This guide provides a professional, step-by-step pathway to successfully move your existing automations to Flow, ensuring your org remains fast, clean, and future-proof.
Phase 1: The Migration Mindset and Strategy
Before clicking a single button in Flow Builder, you need a smart, consolidated strategy. The goal isn’t a one-to-one recreation; it’s consolidation and optimization.
1. The Core Best Practice: One Record-Triggered Flow Per Object
In the past, you might have had ten Workflow Rules and three Process Builders running on the Account object. This is inefficient.
The new best practice is to aim for one primary Record-Triggered Flow per object (e.g., one flow for the Account object, one for the Opportunity object). You will use the Flow’s powerful Decision elements to handle all the branching logic that was previously spread across multiple separate automations.
2. The Golden Rule: Build in Sandbox, Test Rigorously
Never make automation changes directly in Production. Always perform the full migration, testing, and deactivation process in a Sandbox environment first.
3. Identify and Prioritize Your Automation
Use a simple spreadsheet to audit your WFRs and PBs. Focus first on simple automations, then move to complex ones.
| Automation Name | Object | Type | Functionality | Complexity | New Flow Context | Priority |
Update_Opp_Owner | Opportunity | WFR | Update owner if stage is ‘Closed Lost’ | Low | After Save (DML) | High |
Complex_Lead_Conversion | Lead | PB | Create tasks, update related records | Medium | After Save (DML/Related) | Medium |
Phase 2: Step-by-Step Migration of Workflow Rules
Workflow Rules (WFRs) are generally the easiest to migrate, especially those with only simple field updates or email alerts. Salesforce has provided a dedicated tool for this.
Step 1: Use the Migrate to Flow Tool (Recommended for Simple WFRs)
For WFRs that perform basic field updates, email alerts, or tasks, the built-in tool is your friend.
- Navigate to Setup and search for Migrate to Flow.
- Select the Workflow Rule you want to migrate.
- Click the Migrate to Flow button.
The tool automatically converts the WFR’s criteria, immediate actions, and time-dependent actions into a new, inactive Record-Triggered Flow.
Step 2: Review and Optimize the Generated Flow
The automatically generated Flow is usually a good starting point, but it might not be optimized.
- Check the Trigger: The tool often defaults to an After-Save Flow. If your WFR only does a field update on the same record (which most do), you should change the Flow to Before-Save.
- Goal: Before-Save is 10x faster because it updates the record in memory before it’s saved to the database, avoiding a separate DML operation.
- Consolidate Logic: If you’re moving multiple WFRs for the same object, copy the logic from the new flow’s Decision and Update Record elements and paste them into your single, main object Flow.
Simple Drawing Concept:
WFR: (Entry Criteria) -> (Immediate Action)
Flow (Optimized): (Start Element: Before Save) -> (Decision: WFR Criteria?) -> (Assignment: Field = Value)
Step 3: Handle Time-Dependent Actions (Scheduled Paths)
Flows handle WFR’s time-dependent actions beautifully using Scheduled Paths.
- In your Flow, when defining the action elements, use the Add Scheduled Paths option.
- You can set the schedule based on a specific date field or elapsed time (e.g., 5 days after
Opportunity Close Date). This directly replaces the functionality of a time-dependent workflow action.
Step 4: Activate and Deactivate
- Thoroughly test the new Flow in your Sandbox.
- Once confirmed, Deactivate the original Workflow Rule.
- Activate the new Flow.
Phase 3: Step-by-Step Migration of Process Builder
Process Builder (PB) migration is more complex due to multiple criteria, more action types (like creating related records), and scheduled actions. While Salesforce is building a tool for PBs, manual recreation and consolidation is often the best and most performant approach.
Step 1: Document the PB’s Criteria and Actions
Process Builders often have multiple Criteria Nodes (the diamond shapes). Map out each node to understand what it does and when it runs.
| PB Node | Criteria | Actions (Type) |
| 1. High-Value Opp | Amount > $100K | Create Task, Send Email Alert |
| 2. Follow-Up | Stage = 'In Progress' | Scheduled Action (3 days later) |
Step 2: Create the Record-Triggered Flow (After-Save Context)
Since Process Builders can create/update related records and use immediate DML, the replacement Flow must almost always be an After-Save Record-Triggered Flow.
- Navigate to Flow Builder.
- Select Record-Triggered Flow.
- Set the Object (e.g., Opportunity).
- Set the Trigger to A record is created or updated.
- Set the Optimize the Flow for to Actions and Related Records (After Save).
Step 3: Recreate Criteria as Decisions
Each of your PB’s Criteria Nodes becomes a Decision element in your Flow.
- Drag a Decision element onto the canvas.
- Give the Decision a clear name (e.g.,
Is High Value Opp?). - Create an Outcome for each PB criteria path (e.g.,
HighValueOpportunity). - Use the Flow’s $Record variable to reference the fields in your criteria (e.g.,
$Record.Amount > 100000).
Drawing Concept: PB Node to Flow Decision PB:
(Node 1: High Value) -> (Node 2: Low Value)Flow:(Start) -> (Decision: Check Criteria)
--Path 1 (High Value)--Path 2 (Low Value)--Default Outcome
Step 4: Rebuild Actions with Optimized Elements
- For Field Updates (on related records): Use the Update Records element.
- For Creating Records: Use the Create Records element (for creating Tasks, Child Records, etc.).
- For Email Alerts: Use the Action element and select the existing Email Alert you set up in Salesforce Classic. You do not need to recreate the Email Alert!
- For Scheduled Actions: Use Scheduled Paths within the Start Element, just like with WFRs.
Step 5: Deactivate and Consolidate
Once you have rebuilt all nodes and paths from one or more related Process Builders into a single, comprehensive Flow:
- Test thoroughly in the Sandbox.
- Deactivate the original Process Builder(s).
- Activate the new Flow.
A Crucial Note on Order of Execution
When running both Before-Save and After-Save Flows on the same object, the order is:
- Before-Save Flows (best for same-record updates)
- Validation Rules
- After-Save Flows (best for DML on related records, creating records, sending emails)
Use this order strategically to ensure peak performance and stability.
Conclusion: The Future is Fast and Flow-Powered
Migrating from Workflow Rules and Process Builder to Flow is a project that pays dividends in performance, maintainability, and administrative sanity. While the initial audit and manual rebuilding of complex Process Builders take time, the result is a unified, scalable, and powerful automation engine for your Salesforce organization.
Embrace the power of Flow Builder today—your future self (and your users) will thank you for it!