In Part 2 I covered great features: Mobile, Flow Editor, Automation Flows, Dynamics, Screen Flows, User Import, and Reports of Subscriptions to Reports. I also mentioned some things that didn’t make me very happy.
Now in part three, we’ll look at the feature that will probably be most talked about for a long time: The Flow Migration Tool
We already received a Workflow Rule migration tool, and, rather than build two tools, they combined them into one flow migration tool. The tool (available in the setup menu by searching for migration) shows you all the “legacy” automations with sort options on each column. This allows you to figure out things like how many Workflow Rules you have or how many Process Builders. Or how many on each object of any time. And which are active or inactive. Nice!
Using the tool, I learned that I have 9 pages of legacy automations, 1/3 process builder and 2/3 workflow rules. Sorting by objects, I reviewed objects that I have performance concerns about. I’ll prioritize moving from Process Builder to Flow in the coming months.
Workflow rule migration to flow is one-for-one. The workflow rule is disabled and the flow activated automatically. That’s simple, although not all workflow rules can be migrated (e.g., cross object formulas are not yet handled.)
Process Builder rules are more complex. They are made of a series of nodes that may continue or may stop. (Remember the advice to have one Process Builder per object? As a result, we have a lot of tangled up business processes that are very hard to maintain. This is NO LONGER advised.) When you migrate a Process Builder rule, you are shown the different nodes by name and given some advice. (Thank goodness for those names!) You can migrate all the nodes, or you can migrate one or several nodes separately. Thus one Process Builder rule can migrate to multiple Flows. For this reason, the Process Builder rule is not deactivated nor the Flows activated automatically. Some process builder nodes cannot yet be migrated with this tool as of yet due to the type of actions they perform.
I tested the migration on some single node Process Builder rules and it worked. The decision was set as the trigger conditions. The Process Builder update actions became Flow updates actions It was very easy to read and would be no problem to maintain. You’ll want to rename it and add some good descriptive information so you can begin to care and maintain it.
When I converted a much more complex flex, en masse, it resulted in a huge long flow. It would be possible to maintain it since each node has the original labels. But that’s not the only difference! There are no trigger conditions for the Flow so it would be inefficient (although ten times faster than Process Builder). It didn’t seem too awful and if it represents only one business process you can add some trigger conditions and you’ll be done. But I’d still prefer to migrate different business processes in parts… it’s pretty easy to see three separate business processes on our contact handler: deceased handing, newsletter and SMS opt-in handling, and creating automatic referrals and affiliations from a lookup. Those make so much more sense. And if none of those few involved fields are updated, none of them will run, as compared to my Process Builder rule which runs thousands of times a day on every update to a contact. The green energy savings alone wants to make me do it soon!
I tested what happens when I convert a few nodes of a complex Process Builder rule, in this case, all nodes that relate to a contact being marked as deceased or a specific date of death being set. It’s a pretty legible process. No trigger conditions are provided, but since there are three decisions, it would be simple to add conditions and it would be pretty efficient! Note that I’d have to modify the legacy Process Builder if I wanted to activate this new flow. Having both active would likely be bad.
Despite the potential to save energy, I won’t be migrating soon without a reason just because I have plenty to do! I’m adding the items that are probably slow to my technical debt list and will work on them together with other items when I need to modify automation on an object. If I need to change a business process automation, I’ll move any Process Builders or Workflow rules to Flow. I see no urgency to hurry. Decomposing the multi-node Process Builders may take some thought and time, especially the validation and testing steps.
I’m sure lots of experts will start giving us tutorials and strategies on how to migrate best. I can’t wait to hear from them!
As a further example of how you might start thinking about it all, I have EIGHT process builders on one custom object that we use once per client visit every date. There is a noticeable lag when you save records. They are mostly “single node” Process Builder rules so conversion is straightforward by migrating directly to the same named flows, one for one. However, one of them has a high maintenance churn because it has to be updated every time we change team member assignments. We’ll not convert that but instead implement in flow using a business process that can use metadata and not require hard code updates. Some limitations from legacy automation are better addressed in a new way, like this one! I have FOUR process builders on Volunteer Hours, which we use for every service delivery to clients (10,000 times a year). Most of those are multi-node performing unrelated business processes. I’ll want to convert those a few nodes at a time so that I have flows that make sense and I can make full use of flow trigger conditions to keep things efficient. This will also take some planning. This will require quite a bit of planning and testing