My Initial Reaction to the Migrate to Flow Tool for Workflow Rules
I’ve Now Tested Out the Migration Tool for Flow, Here’s My Thoughts
So, earlier on today I finally got around to trying out the Migrate to Flow tool that is currently in beta and is coming to Production Orgs as part of the Spring ’22 seasonal release from Salesforce. There’s already been lots of content produced about the tool, so do go and check that out. However, in this brief post, I want to give a bit of an overview of the tool, how it works, and my thoughts overall on it. Before I dive in, let me just say that my thoughts on the tool are a little bit mixed, but I’ll get into the reasons for that later on. For now, let’s dive into the part of all of this that I think is a 100% positive.
Salesforce Encourage You to Use Flow In Setup
This is my true highlight of the process overall. When the Admin goes into setup and navigate into Workflow Rules you will see the notice shown below.
The notice here notes about the plans to retire Workflow Rules and suggest building automation in Flow Builder. The notice then provides with links to the reference blog, Go with the Flow: What’s Happening with Workflow Rules and Process Builder? and a link to the migration tool itself. The other really cool thing about this is that when you first navigate to Workflow Rules in Setup with the Spring ’22 release activated, you get a nice little popup saying something very similar and giving you a link to navigate to Flow Builder instead. Unfortunately, I don’t have a screenshot of this, but it’s a very handy thing to have. I think if Admins can be provided with as much encouragement as possible to start using Flow over Workflow Rules and Process Builder, it will serve to make the transition period more effective and pain-free.
Now, let’s get into the migration tool itself. First I’ll go over how the tool works, then I’ll provide my thoughts on the tool to end the post.
Using the Migration to Flow (Beta) Tool
The tool in of itself is relatively simple, to begin you will need to navigate to Setup, and to navigate to Process Automation and Migrate to Flow (Beta). Alternatively (and much more quickly), you can simply type migrate (or as shown in the screenshot, migra) and you’ll see the link for the tool appear.
Now when you click on the link you will be taken displayed above. As you can see from the screenshot, you can’t migrate multiple Workflow Rules into a single Flow (I’ll pick up on that later on), the tool in its current form only allows for a 1–1 conversion. Meaning, 1 Workflow Rule is converted into 1 Flow. So bear that in mind during the migration process. Once you have selected the Flow you want to migrate, you can click the Migrate to Flow button, or you can click on the dropdown menu icon and select it from there.
From there, the migration tool begins to run, and you then see this:
The screenshot above shows that the migration is now in progress. There’s not a great deal to add here in terms of notes, we do not see the work going on under the hood, but what is going on here is that the tool is scanning your Workflow Rule and creating elements and starting conditions based upon the rule that you have created. The migration of the Workflow Rule I created and used in the migration was completed very quickly (less than 1 minute). I’d imagine that Workflow Rules with more actions in them would take more time to convert, however, my workflow was a simple email alert if the entry condition matched the requirements that I set. So there was only one element to create along with the entry criteria that I used to fire the Workflow Rule.
Once the migration is completed, you are greeted with a screen asking if you would like to view the newly created Flow in Flow Builder or to switch the Activations. Switching the Activations will deactivate the Workflow Rule and activate the Flow. This is something I will also get back to shortly.
Clicking the Test in Flow Builder button will take you to your newly created Flow in a new tab. In this screen you can see the name it created. In the case of the Flow that was created, a description is auto-populated with a note on which workflow rule was migrated along with the workflow rule description. The label used is the same label as your Workflow Rule and the API name copies across the name of your Workflow Rule and formats it to the auto API formatting that is used in Flow (again thoughts on that in a little bit).
Here is the final result for the label, API name and description of the Flow that I created when testing out the tool:
- Flow Label: High Priority Case Closed w/ Phone as Source
- Flow API Name: High_Priority_Case_Closed_w_Phone_as_Source
- Description:
Migrated from the: High Priority Case Closed w/ Phone as Source workflow rule
Workflow rule description: This workflow triggers when a high priority case that was received over the phone was created.”
Please note that the Flow’s API version will be 54 (relevant for deploying with tools like Gearset) and no Trigger Order will be assigned upon migration.
The next few screenshots, show the Flow that was created via the Migration.
As you can see from the screenshots above, this is a pretty cut and dry conversion. The tool pulls in the conditions and actions in your Workflow Rule and then simply replicates them into a Record-Triggered Flow. There’s not much more to detail here that can’t be covered in the screenshots above. So do make sure to spend a little bit of time looking at them to understand how the migration tool works in practice. Once you’re happy with the Flow, you can either activate in Flow, or you can go back to your Migration tool page that should still be open in another tab and click on the Switch Activations button. When you do that you will see the following view, obviously this will be slightly different depending on how many Workflow Rules you have in your org. In the dev org I used to test the migration I only have the two.
OK, so that’s a bit of an overview of how the tool works. But what do I think of it as a tool overall? Well, let’s get into that a little bit shall we?
My Thoughts on the Migration Tool
In brief, I think the tool is OK for what it is. The tool is clearly designed to be a straight like-for-like conversion of Workflow Rules to Flows. So from that view the tool is fine, it does exactly what it is designed for and it works well when viewed under that lens. My issue with the tool in all honesty is that in many instances simply doing a 1–to-1 conversion may not be best practice. For example, how many Workflow Rules are created that are a part of the same business process and should arguably created in a single Flow, or at the very least a Flow that is connected to one or more SubFlows. So it is mainly for that reason why I feel that this tool could potentially lead to issues relating to best practice. After all, if you migrate all of your Workflows and then find yourself spending a ton of time addressing issues around have multiple Flows that you probably could’ve merged into one, then what is the real benefit of the tool?
This is why I have mixed feelings about the tool. I feel that we could be potentially teaching Admins some bad habits when it comes to managing their declarative automation. Granted, with the inclusion of the order of execution field inside of Record-Triggered Flows, which in my opinion could be a real game-changer, some of these concerns are minimised as the limit to the number of Flows that can be included in the order of execution is 2,000. One does have to ask, should we even have 2,000 Flows running from a single object? 2,000 Flows is a heck of a lot of automation to manage and maintain.
In summary, I think the tool is fine to use for those Workflow Rules that can be migrated in a strictly like-for-like capacity, however, I can’t in good conscience recommend it as the primary method for migrating older automation into Flow. I’m sorry to say that, but that’s just my opinion. Once again, it’s fine for what it is, but ALL of your Workflows should be thoroughly evaluated before beginning the migration process. For the purposes of clarity, I don’t think there is anything necessarily wrong with the tool based on what we can identify as being it’s purpose from how it was built, I just feel that as an Admin there’s much more to the migration than simply copying everything into Flow, and I feel that this tool could potentially lead to further headaches for Admins down the line. Basically, use the tool, but do so wisely is the moral of this story. Before using it, ensure that you only migrate the automation that makes sense to be a straight like-for-like conversion, if that kind of conversion isn’t right for that particularly business process, build it from scratch in Flow.
Closing Remarks
Before I close, I just wanted to highlight that I will be releasing a new post in the coming weeks (probably mid-February) with my tips for migrating your older declarative automation into Flow. So keep an eye out for that in the coming days. With all that being said, if you’ve used the migration tool, I’d love to hear your thoughts on it. Did you like it? Do you think it’s something that you will use as you work on migrating your Workflow Rules into Flow? Let me know your thoughts in the responses below, or on social media.
