In Blog, Flow, Process Builder

Brian Kwong Photo

Migrating Process Builder to Salesforce Flow

Dreamforce 2021 made the surprising announcement that Workflow Rules and Process Builder will be retired. This is going to happen over the next few years. It’ll start by not allowing Salesforce customers to create new Workflow Rules or Process Builders. Eventually, you won’t be able to edit your existing ones. This means we should start planning on migrating our automation to Flow and planning new automation needs with Flow in mind. You can read a great summary from SalesforceBen in his post

Migrating Process Builder to Flow Considerations

Flow can seem very daunting. It’s made huge improvements over the last two years to become more user-friendly and easier to use. There are a few schools of thought on how we can migrate.

  1. We create 1 Flow for each Process Builder
  2. We Create 1 Flow for each Process “node” (those blue diamonds)
  3. We create the fewest number of flows per object, combining multiple workflow rules into each flow

There’s not really a cut-and-dry answer on what’s the best method. In practice, it is going to depend heavily on what the Process is doing. For example, if you have an Opportunity process that makes field updates only to the Opportunity that triggers the automation – then it may make sense to have 1 before-trigger Flow with decision elements to mirror any Process node (blue diamonds) criteria. If your Process is a mix of field updates to the opportunity and other actions, you could still potentially go the single Flow route, but you may find you gain more performance by splitting it into 2 – a Before-Trigger Flow to handle the Opportunity updates and an After-Trigger Flow for the other actions.

The other wrinkle are any scheduled actions. Similar to Time-Based actions in Workflow rules, Flows can only handle the criteria for when to schedule actions in the start element. This means if your criteria is “when an opportunity is closed/won send an email 7 days after CloseDate” you MUST use a single Flow where the criteria defined in the Start element handles “Opportunity is Closed/Won” and then schedule a path for 7 days after CloseDate. I talk about this a bit more in the Migrating Workflow Rules to Flow video.

There are some benefits to having one Flow per object. The biggest benefit is the control over what actions occur. This is going to be mitigated by a Salesforce Spring ’22 release that was teased by Diana Jaffe one of the Product Managers of Flow. Trigger Ordering is going to remove the pressure of wanting a single Flow per object to handle order of actions.


The video is from the live stream where I migrate a Process Builder to Flow. This single Process became multiple Flows. I talk about the rationale behind what got split into which Flow and walked through the build step by step. I also showed how you can group multiple Process Nodes (Blue diamonds) into a single Flow, but the more I see the roadmap for Flow the more I’m thinking that isn’t the best approach. With exceptions, generally, you’re going to want to have a single Flow for each Process Node in your Process.

Check out other Wizard’s Apprentice videos:

I have a whole series on building Flows. Some of them are on the old cloud designer. Some are on the new Lightning Flow Builder. Flow has made a lot of updates so some of the wordings and screen appearances have changed, but the underline concepts still apply. You can find these under Wizard’s Apprentice.

Lightning Flow Builder: Resources! Wizard’s Apprentice Episode 4

Wizard’s Apprentice: Lightning Flow Builder Overview

Recent Posts

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Migrate Workflow Rule to FlowFlow Orchestrator Build