The Timeline, Without the Marketing Gloss

Salesforce announced the retirement of Workflow Rules and Process Builder years ago. Here’s the state of play as of early 2026.

  • Workflow Rules: creation of new ones has been disabled for existing customers. Existing rules still run, but Salesforce has signaled end-of-life windows that continue to tighten. You cannot assume they’ll work indefinitely.
  • Process Builder: same pattern. Existing processes run, new ones can’t be created in most orgs, and end-of-life is being signaled release by release.
  • Flow: the only supported path forward. Every new automation should be built in Flow.

The specific dates have shifted more than once. Rather than tracking announcements, plan as if both technologies will be turned off by the end of the coming fiscal year. If the dates slip again, you lose nothing.

Inventory First

You can’t migrate what you haven’t inventoried. Before touching anything:

  • Setup → Workflow Rules — count active rules per object.
  • Setup → Process Builder — list active processes with their triggers.
  • For each, note:
    • Object
    • Trigger criteria
    • Actions (field updates, email alerts, tasks, outbound messages, invocable actions)
    • Active status
    • Last modified date and author

Export this inventory to a spreadsheet. It becomes your migration roadmap and your completion scorecard.

The Migration Tool

Salesforce ships a Migrate to Flow tool in Setup → Migrate to Flow. It converts many Workflow Rules and Process Builder processes into equivalent flows automatically.

What the tool handles well:

  • Simple field updates.
  • Email alerts with merge fields.
  • Create-record actions.
  • Time-based workflows with scheduled actions.

What the tool struggles with:

  • Complex cross-object updates.
  • Processes with many criteria groups and branching.
  • Actions calling unmanaged packages or deprecated APIs.
  • Rules using formula fields with edge-case behavior.

Always treat tool output as a starting point, not a finished migration. Every auto-converted flow needs review before activation.

Not every rule is equally urgent. Tier your migration:

Tier 1: Business-Critical

Rules on Case, Opportunity, Account, Lead. These run on every transaction touching those objects. Migrate first, with extensive testing.

Tier 2: Operational

Rules on custom objects driving day-to-day operations — inventory, renewals, territory assignments.

Tier 3: Notification-Only

Rules that only send emails. Least risky to migrate, but still necessary.

Tier 4: Dormant

Rules marked active but rarely triggered. Audit before migrating — many of these can be retired rather than moved.

What a Converted Flow Should Look Like

A good rule-of-thumb migration converts each Workflow Rule into one Record-Triggered Flow. Consolidate related rules on the same object into a single flow with Decision branches — but only if that makes maintenance easier, not just to reduce flow counts.

For each converted flow:

  • Set the trigger correctly (create / update / both; before-save or after-save based on the actions it performs).
  • Match entry criteria to the original rule’s conditions.
  • Reproduce each action — field updates, email alerts, outbound messages — using flow equivalents.
  • Add fault handling the original rule didn’t have.
  • Name the flow after the rule it replaces, for traceability.

Field-Level Updates: Use Before-Save

If the original Workflow Rule only updated fields on the triggering record, the converted flow should be a before-save Record-Triggered Flow. Before-save flows don’t consume extra DML for field updates — they’re the efficient equivalent of Workflow Rules’ field updates.

An after-save flow doing the same job is correct-ish but wastes resources at bulk scale.

Email Alerts Still Work

Email Alerts (the metadata objects defining subject, body, and recipients) are reusable from Flow. You don’t need to recreate them. Your flow can invoke the existing Email Alert via a Send Email action.

This is the easiest part of the migration — almost zero rework.

Outbound Messages: Check the Receiver

Workflow Rules’ Outbound Messages pushed SOAP messages to external systems. Flow’s External Services and HTTP Callouts are the modern equivalent but have different calling semantics and auth handling.

Before migrating an Outbound Message, confirm the receiver can accept a different payload shape. You may need to update the external system or add a transformation Flow step.

Time-Based Actions

Workflow Rules’ time-based actions (run X days after criteria met) map to scheduled paths in Flow. The mapping is clean, but Flow scheduled paths have nuances:

  • Scheduled paths run based on a DateTime field you specify — not generically “X days after evaluation.”
  • The scheduled path fires even if the triggering criteria no longer match at runtime. Re-validate inside the path.
  • Scheduled path executions are visible in Setup → Time-Based Workflow → Scheduled Paths.

Testing the Migration

Every migrated flow needs testing. For critical flows, build a Flow Test suite (see the Flow Testing article) and run it in CI.

For rules that are hard to test programmatically (emails, outbound messages), test in a sandbox by triggering realistic scenarios and observing outputs.

Deactivate, Don’t Delete

When a flow is live and verified, deactivate the Workflow Rule or Process. Don’t delete. Deactivated rules remain in metadata for audit and easy rollback.

Only delete after a stable period — typically one full release cycle — has passed with no issues.

What If You Miss the Deadline?

If Salesforce disables execution of your legacy rules and you haven’t migrated, existing automation simply stops running. Records won’t get the field updates. Emails won’t go out. Integrations waiting on outbound messages will silently receive nothing.

Nothing catches fire immediately, but business processes quietly break. By the time anyone notices, days of data may be in inconsistent states.

Don’t miss the deadline.

Frequently Asked Questions

Can I keep a Workflow Rule indefinitely if it’s still working?

No. End-of-life is coming. “Working” today is not a guarantee.

What about Approval Processes?

Approval Processes are separate metadata and have their own roadmap. They are not currently being retired on the same schedule. Migration to Flow Orchestrator is optional but encouraged for complex approval chains.

Does the Migrate to Flow tool cost anything?

No. It’s part of the platform.

Will Salesforce migrate my rules for me?

No. Migration is your responsibility. Salesforce provides tooling and documentation but does not migrate customer orgs.

Share