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 organize 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
- Branch 1: Title contains ‘CFO’
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!
Comments: