Migrate Salesforce Workflow Rules & Process Builder to Flow (+ Video)

Share this article...

Flow has long been my personal favourite declarative (clicks-not-code) automation tool that Salesforce has launched, the versatility and power that Flow offered astounded me – as someone who had little-to-no coding skills at the time, I was always intimidated with the thought that I’d never be able to create complex, business-grade automation or UI tweaks without the help of a developer.

Flow changed all that for me, and Salesforce’s main focus for the next few years is to retire Process Builder and Workflow Rule automation, Flow will then be the only tool that Salesforce professionals need to build powerful automation, and innovate at a faster rate than ever before.

The Future of Salesforce Declarative Automation

During the True to the Core session at Dreamforce ‘21 (watch it here on Salesforce+ if you haven’t already), the future of Salesforce was discussed by Parker Harris, Jennifer Sacks, Bret Taylor, and David Schmaier – including the future of declarative automation on the platform. One important piece that was mentioned and has echoed throughout the community ever since was the phasing out of Process Builder and Workflow Rules so that Salesforce Flow was the all-in-one tool for declarative automation. 


What happens to existing Processes and Workflow Rules? These will need to be migrated into Flow Builder, and Salesforce is already hard at work building a migration tool to do just that. Keep on reading to get a preview of the new Workflow migration tool, and Process Builder migration coming shortly after as an add-on. That being said, there are other third-party tools already on the market that you can use to migrate your legacy automation into Flow Builder.

I’ll talk more about these further down.

Why Flow?

The question that a lot of people have been asking me is why is Salesforce removing two of their staple automation tools from the platform and forcing everyone to use Flow. Their reasoning at surface level was to make it so that there was a single tool that Salesforce Administrators could go-to for any and all declarative automation requirements. But the question remains – why should Flow be the go-to automation tool going forward?

The answer is fairly simple – Salesforce Flow includes a multitude of functionality that Workflow Rules and even Process Builder simply can’t do. When you compare Flows, Processes, and Workflow Rules to their far more complex ancestor, Apex, you’ll notice that Flows share a lot of the same concepts, technical language, and even functionality. Flow was the first declarative tool that Salesforce offered that could be triggered by the deletion of a record (without a fancy Roll-Up Summary trick, or similar).

Flow is also the only declarative tool that offers the ability to handle multiple records at once in a Collection (or a List in Apex terminology). Flows also support looping, which means that a Collection of variables or records can be iteratively processed one-by-one, meaning that a single automation is required to perform complex processing, and automations can be done in bulk. There’s no simple way to handle multiple records with complex logic using Workflow Rules or Process Builder, as this is functionality that has existed solely within Flow Builder since its inception.


You’ll also need to consider things like the Order of Execution – what’s the best way to organise your Flows in a structured way so that they’re always triggered in the order you’re expecting them to. Similar to how you’d have a single Process per object, you will need to consider a similar structure for your Record-Triggered Flows. To read up on best practices and a wealth of other process automation information, head over to the official Salesforce Architects Record-Triggered Automation page.

Business Scenario and Best Practice Concepts

Let’s use the following hypothetical example: Each time a new Contact is added to an Account, and the Contact has ‘CEO’, ‘COO’, or ‘Director’ in their title, you need to add them as an Opportunity Contact Role to each active Opportunity as a ‘Decision Maker’. Each time a new Contact is added to an Account and has ‘CFO’ in their title, you need to add them as an Opportunity Contact Role to each active Opportunity as an ‘Economic Decision Maker’. There’s quite a bit going on in those requirements, so let’s break it down:

  • Any time a new Contact is added to an Account (this is the trigger)
    • Branch 1: Title contains ‘CFO’
      • Add to all existing Opportunities as ‘Economic Decision Maker’
    • Branch 2: Title contains ‘CEO’, ‘COO’, or ‘Director’
      • Add to all existing Opportunities as ‘Decision Maker’
    • Branch 3: Else (anything that doesn’t match the first 2 branches)
      • No additional functionality at this stage

With Flow Builder, you can create a Record-Triggered Flow that picks up any time a new Contact is added to an Account. You can then create branches that behave differently depending on additional criteria, and perform different functionality based on this criteria. 

The reason you may want to do this is from a DML limits perspective – notice I referred to Branch 3, even though there was no additional functionality. The reason I highlighted this point is to show that there was no additional querying of Opportunity records, or attempt to update records when there was simply no need to do so. This helps to keep your DML usage and system pressure low.

Migration Considerations and Developing a Migration Strategy

As always, the most important thing before making a major change like this to your Salesforce environment is putting a strategy in place and planning how it will be done. Performing a major migration of your Salesforce automations isn’t something you want to rush and requires rigorous testing to ensure that nothing has broken in the process.

It may be worth taking the time to analyse each of your automations before migrating them to Salesforce Flows. Given that the technology available to you in Flow Builder is quite different and will likely include additional features, there may be a better way to build your automations. It may be a good idea to rebuild and combine a number of automations, rather than simply perform a 1-1 migration.

With any other Workflow Rules and Processes that you’re not going to rebuild and merge by building new Flows, you’ll need to consider how you’re going to migrate them into Flow using either an official Salesforce migration tool, or a third party migration tool. As with anything you do in Salesforce, you should be testing everything in Sandbox prior to moving into Production to make sure no functionality is lost during the migration.

Salesforce Migrate to Flow Tool

As mentioned above, Salesforce is looking to release their first official migration tool in the upcoming Spring ‘22 update, which will allow you to migrate Workflow Rules to Flows. Later this year, this tool will be enhanced to allow for Process Builder migration to Flow as well. 

Using the Salesforce Migrate to Flow Tool

Migrate to Flow is in beta in Spring ‘22 Preview Orgs, and will be available in Sandboxes and Production environments. Let’s have a look at what the tool is and how it works. To open it, navigate to the Setup menu and search for ‘Migrate to Flow (Beta)’. You will be presented with a list of Workflow Rules that can be migrated to Flows using the tool (in this example, there’s just one).

To migrate our Workflow Rule to a new Flow, all we need to do is check the radio button next to our Workflow Rule, and click Migrate to Flow. After a few seconds (depending on the complexity of your Workflow Rule), you should see a success screen come up letting you know that your new Flow has been created, but is inactive. At the top, there’s the Test in Flow Builder button. This allows you to quickly open your new Flow in Flow Builder and make sure everything has migrated as expected.

Once you’ve reviewed the resultant Flow, you can feel free to click the Switch Activations button. Assuming your Workflow Rule was Active, this will deactivate the Workflow Rule and activate the Flow.

That’s it! Salesforce’s new tool makes migrating away from Workflow Rules an absolute breeze. It is still worth analysing your legacy automations before migrating them, and potentially rebuilding them from scratch as a single Flow. This will keep the number of Flows in your org to a minimum, and make it easier to maintain them moving forward.

Third Party Migration Tools

Salesforce may be building the first OFFICIAL tool, but they’re certainly not the first to create a Flow Migration tool of any kind. One that’s become quite popular in the last few months is ConvertToFlow v2, by Alex Edelstein on UnofficialSF. It’s recently been revamped (hence, version 2 in the name) and supports both Workflow Rules and Process Builder. That being said, it’s still in development and there are a number of features it can’t quite do yet.

When migrating a Process, the ConvertToFlow tool will create a clone of the original Process as a Record-Triggered Flow. It’s worth noting that the original Process is left in an as-is condition, and is not deactivated. When you go to activate the new Flow, make sure you’ve switched the Process off. The new Flow is also created with ‘converted_’ at the beginning of the name (you may want to clean this up before activating your Flow).

Summary

There’s no doubt that Salesforce is doubling down on Flows as their primary declarative automation tool. Depending on your business, and depending on the resources available within your business, you may or may not want to begin the process of migrating your legacy automations sooner rather than later.

Remember, it’s important to strategise and test your migration prior to releasing directly to Production. Even if you’re willing to wait for the official Salesforce tool, this doesn’t mean that the migration will work flawlessly! Always have a contingency plan in place, and test test test!

10 thoughts on “Migrate Salesforce Workflow Rules & Process Builder to Flow (+ Video)

  1. Great content as usual Tim! The one point (that you mentioned) and needs to be emphasised is that simply converting workflows or process builder automations to flow will simply give you all your old junk in a new tool. This is an opportunity to review and redesign many old automations using the new tools and their extended capabilities.

  2. QQ: re: Workflow rules used in approval processes – any idea how that conversion process works? E.g. how is one going to call the flow from the approval process when it was previously a workflow rule?

    1. Christine Marshall

      Reply

      Hi Laura,

      Sometimes it takes a few minutes for the quality to improve. I found that when I initially looked at the video it was low quality, but after about 30 seconds it was high quality. I also found the quality improved when I switched the video to fullscreen. Hope this helps!

  3. As easy and uncomplicated you are making Flows sound, they are not easy. There will be many admins and super users who will see their workflows and processes and not understand how they will work in Flow. In addition, creating a Flow from scratch is not intuitive and in my business case, NONE of the Trailheads address my situation or general examples that I could use. We have more than 50 processes and at least 50 workflows in use at this time.

    Not happy about this at all, but understand that there is no choice but to learn this (NOT) easy new method.

  4. Hi SalesforceBen Team,
    Thanks for the informative posts. I have one question – while using this migration tool sometimes i don’t see my all process builders to migrate. Let’s suppose i have 10 processes to migrate but i can only see 7 of them. Why this behaviour? Any help would be appreciated.

    Thanks!!

  5. I tried to install ConvertToFlow v2, by Alex Edelstein on UnofficialSF but I didn’t manage to use it because there is no user guide. Normally the is a ConvertToFlow page from which we should be able to select a process builder.

Add Comment