Written by: Doug Camplejohn, CEO & Co-Founder, Coffee
Key Takeaways
- Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, so migration to Flow is now a cleanup project.
- A risk-tiered migration approach moves from simple field updates to complex Apex-dependent automations, which builds confidence before high-risk work.
- The Migrate to Flow tool converts roughly 70% of legacy automations cleanly but creates separate flows instead of consolidated logic and misses several automation types.
- Pending time-based actions are dropped when original rules are deactivated, so teams must inventory and trigger them manually before migration.
- Maintain Salesforce Data Accuracy While Automations Are In Flux so records stay reliable throughout migration.
Why Salesforce Teams Are Migrating To Flow Now
Salesforce introduced Workflow Rules in 2007 as its first declarative automation framework. It added Process Builder in 2015. Salesforce then announced the deprecation of both in 2021 in favor of Flow. The retirement rolled out in stages. Salesforce first removed the ability to create new Workflow Rules and Process Builder processes, then ended all support on December 31, 2025.
The Migrate to Flow tool exists in Setup → Process Automation to help admins convert legacy automation without starting from scratch. It converts Workflow Rules and Process Builders cleanly in roughly 70% of cases. The remaining 30% require manual rebuilding. The tool performs one-to-one conversion. It does not consolidate logic, audit behavior, or warn about risk patterns.
As of 2026, the record-triggered Flow is the most-used automation primitive on the Salesforce platform, and Flow is the only framework where Salesforce accepts net-new declarative builds in production orgs. Trailhead’s “Flow Testing and Distribution” module and the official Migrate to Flow documentation cover mechanics. They do not address sequencing decisions, failure modes, or data-quality consequences while production stays live.
The Risk-Tiered Migration Order For Salesforce Workflows And Automations
This playbook sequences migrations from lowest to highest risk. Run each phase in a full sandbox before deploying to production. A full sandbox includes production data and metadata, which is essential for testing time-based actions, cross-object updates, and edge cases that only appear with real data.
- Phase 1 — Simple Field-Update Workflow Rules: Single-object, immediate-action rules with no cross-object dependencies are the safest starting point. The Migrate to Flow tool converts these into before-save record-triggered Flows correctly. Before-save flows commit field changes before the record is written to the database. That behavior removes an entire category of DML limit errors that Process Builder often caused. Effort estimate: 15–30 minutes per rule.
- Phase 2 — Email Alerts: Salesforce Email Alert objects are independent of the automation tool that triggers them, so a new record-triggered Flow can reference the same existing Email Alert without recreating its template, recipients, or sender configuration. The critical failure mode is duplicate sends. Without a change-detection condition using
{!$Record__Prior.StageName}, the Flow fires on every save while the condition is true. The original Workflow Rule usually fired only on the field change. Effort estimate: 1–3 hours per rule. - Phase 3 — Process Builders With Single-Object Logic: Process Builder runs record-by-record rather than in bulk, which makes it the source of many governor limit errors on high-volume objects. Converting single-object Process Builders to record-triggered Flows removes that bottleneck. Map each Process Builder decision group’s AND/OR logic carefully. The common mistake is building one Decision outcome with mixed conditions when the original process used OR logic. Effort estimate: 1–3 hours per process.
- Phase 4 — Time-Based And Scheduled Automations: Rules with time-dependent actions require the most pre-migration preparation. Pending actions are dropped when the original rule is deactivated, so you need a clear plan for in-flight work. Migrate during low-volume windows so fewer records sit in the queue. Manually trigger escalations that would have fired during that window. The new Flow also behaves differently at fire time. Scheduled paths in Flow re-check conditions when they run, while legacy time triggers evaluated conditions only at entry. Effort estimate: 4–8 hours per rule.
- Phase 5 — Apex-Invoking And Integration-Dependent Automations: Apex triggers and Workflow Rules execute in a defined order, and introducing a Flow can alter that order in ways that are not immediately obvious. Audit every Apex trigger on objects that also have Workflow Rules. Map the execution order, then rebuild any dependencies in Apex before deactivating the rule. Outbound messages have no Flow equivalent and require an Apex callout or External Service replacement, which is often a full integration rebuild. Effort estimate: 1–3 weeks with a developer required.
What The Migrate To Flow Tool Converts And Where It Fails
The Migrate to Flow tool performs one-to-one conversion. An org with 15 Workflow Rules on the same object ends up with 15 separate Flows instead of one Flow with branching logic. The tool omits complexity scoring, effort estimation, and conflict detection between overlapping rules. The table below maps each legacy automation type to its Flow replacement, the level of tool support, and the main failure mode to watch.
| Legacy Automation Type | Flow Replacement | Migration Tool Support | Key Failure Mode |
|---|---|---|---|
| Field Update | Before-save flow | Full for simple same-record updates | None for simple same-record updates. ISCHANGED/ISNEW must be remapped manually. |
| Email Alert | Flow email action referencing existing Email Alert object | Full (references same Email Alert object) | Duplicate sends without change-detection condition |
| Scheduled Action | Scheduled path on record-triggered flow | Partial — pending actions not migrated | Pending queue dropped on deactivation |
| Outbound Message | Flow HTTP callout or External Service | None — silently skipped by the tool | Full integration rebuild required; SOAP format rarely compatible with modern APIs |
The tool also does not support Workflow Rules that use Tasks, fields on related records in criteria, record types, the “does not contain,” “includes,” or “excludes” operators on text/picklist fields, relative date values like TODAY or NEXT WEEK, global variables, or multiple currencies. For these, rebuild directly in Flow Builder rather than attempting a tool conversion.
Handling Workflow Rules With Pending Time-Based Actions
In Salesforce, the time-based workflow queue stores time-dependent actions until their scheduled time arrives. Pending actions leave the queue in one of three ways. The scheduled time arrives and the action fires. An admin manually deletes it from Setup. Or the record that owns it is deleted.
- Inventory what is still in the workflow queue before migration using Setup → Monitor Pending Workflow Actions.
- Migrate during a low-volume window and manually trigger escalations or follow-up actions that would have fired from the queue.
- Re-fetch the record at the start of each Scheduled Path using a Get Records element filtered by Id, then run a Decision element to confirm the record still meets the criteria before taking any action. The record state at fire time may differ from trigger time.
Scheduled paths run in a separate asynchronous transaction context with higher governor limits, 60 seconds of CPU time and 12MB of heap, and are charged against async limits rather than sync limits. They can also be silently canceled if the flow’s entry conditions no longer hold before the scheduled fire time. That behavior often surprises teams when a scheduled job vanishes without explanation.
Subflows Vs. Actions: Consolidation Strategy For Record-Triggered Flows
Salesforce evaluates multiple record-triggered flows on the same object in alphabetical order, and that order can affect outcomes. The long-standing best practice favored one flow per object organized internally with subflows. However, Salesforce’s Flow Trigger Explorer lets admins see every record-triggered flow on an object in execution order and reorder them. That visibility has shifted many teams toward several focused flows per object with a deliberate execution order instead of one monolith.
Several constraints govern where subflows can be used:
- Before-save (Fast Field Updates) record-triggered flows cannot contain a Subflow element. They support only Assignment, Decision, Get Records, and Loop elements. After-save flows are the natural place for reusable orchestration that needs subflows.
- A Subflow element can reference only autolaunched flows and screen flows. It cannot launch record-triggered, schedule-triggered, or platform event-triggered flows.
- Subflows run in the parent flow’s transaction and share the same governor limits. SOQL, DML, and CPU counters are not reset by entering a subflow.
Avoid recursion across flows, where Flow A updates a record that fires Flow B, which updates the same record and fires Flow A again. Use a single flow with internal branches when the logic is related. For recursive Workflow Rule chains, the safe Flow equivalent is a single record-triggered flow with decision elements and a WF_Processed__c checkbox guard that skips the flow if already true.
Testing And Verification Before Deactivating Legacy Automation
Keep the original Workflow Rule active until the replacement Flow has run correctly in production for at least two weeks. Use the following checklist to verify each migration before cutover.
- Bulk Load Test: Load 200 records to check governor limits under volume. A flow that works on one record can fail on two hundred.
- Single-Record Debug Trace: Use Flow Builder’s Debug pane to run both the main path and the skip path. Verify variable values at each step.
- Side-By-Side Comparison Run: Trigger the old process and the new flow against equivalent records and compare the resulting field values.
- Negative Test Cases: Include at least one negative test case per decision element, such as “Customer Type is blank” or “Amount is 0,” because those record states appear frequently in production.
- Post-Deploy Monitoring: Monitor migrated Flows for errors by checking Setup → Flows, Flow Error Emails, and Paused and Failed Flow Interviews for the first several days after production activation.
After verifying a migrated Flow, deactivate the original Workflow Rule rather than delete it. For the roughly 30% of automations that Migrate to Flow cannot convert cleanly, admins should rebuild manually and then delete the originals rather than leaving them disabled-but-present, because a disabled automation in Setup is one careless click away from becoming an enabled regression.
Keep Your Salesforce Data Clean During Migration
Post-Migration Data Quality And Reporting Impact
Reports themselves do not break when migrating from Workflow Rules to Flow because they read field values, not the automation that sets them. If a migrated Flow has a bug that causes field updates to fire at the wrong time or not at all, report data will drift. Outbound message replacements require full integration rebuilds. Any downstream system that consumed those SOAP payloads needs to be re-pointed to the new callout or External Service before the legacy rule is deactivated.
Migration also exposes a deeper data-entry problem. Legacy CRMs like Salesforce rely on busy humans to enter data, and that dependency continues when Workflow Rules become Flows. 71% of sales reps say they spend too much time on data entry, leaving only 35% of their time for selling. When automations are in flux during migration, the manual data entry problem compounds. Records that automations were keeping current now depend entirely on human input.
Coffee’s Companion App for Salesforce deploys as an intelligent agent layer on top of an existing Salesforce installation. The Coffee Agent handles the data-in process, capturing tasks, logging interactions, enriching contacts, and syncing activity from emails and calls. Salesforce records stay accurate without manual effort. Coffee does not migrate Workflow Rules or Process Builder. It addresses the data-quality layer that migration work leaves untouched. Coffee is SOC 2 Type 2 and GDPR compliant, and data is not used to train public models.
How Flow Changes Salesforce’s Automation Operating Model
Process Builder is retired. Existing processes continue to execute, but Salesforce will not fix bugs in them, will not support them when they break after a platform update, and has made clear that the long-term future is Flow. Orgs still running Process Builder are operating on borrowed time.
The operating model shift from Workflow Rules and Process Builder to Flow changed more than the tool name. Workflow Rules evaluated multiple rules on the same object in alphabetical order by name. Multiple record-triggered Flows on the same object run in an order controlled via trigger ordering, which gives admins explicit control that Workflow Rules never provided. Before-save flows run earlier in the order of execution than Workflow Rules did. That timing means naively converting both a Workflow Rule that set a field and a Process Builder that read that field on the same record edit can flip the read and write order.
Conclusion: How To Use This Playbook
Migrating Salesforce workflows and automations to Flow forces teams to surface years of automation debt, resolve sequencing conflicts, handle in-flight scheduled actions, and rebuild integrations that outbound messages were quietly powering. Admins who migrate blindly with the Migrate to Flow tool, without a risk-tiered plan, inherit the same operational mess in a new framework plus new Flow-specific failure modes around recursion, order of execution, and bulk processing.
The playbook above sequences migrations from lowest to highest risk, calls out realistic failure modes for each phase, and provides a testing protocol that catches regressions before they reach production. Migration work still leaves one core dependency in place. Salesforce records stay accurate only when someone or something keeps putting good data in. Coffee’s Companion App for Salesforce deploys as an intelligent agent on top of your existing installation, handling the data-in process automatically so your team spends time selling instead of updating records.
Give Your Salesforce Org A Reliable Data-Quality Layer
