Last Updated on December 11, 2022 by Rakesh Gupta
My name is Pablo Gonzalez. I’m the creator of HappySoup.io and have been a Salesforce developer for 11 years.
Unless you’ve been living under a rock the last few months (and I won’t judge if you have!), you may have heard that Salesforce has plans to retire Workflow Rules and Process Builders in favor of Flows.
The official announcement answers most of the questions you could have about this, so I highly recommend reading it, and I’ll try not to repeat too much about it here. However, the important bit is this:
We want to make Flow your one-stop shop for low-code automation. And we want to ensure that we can throw the full force of our developers into building awesome, new features and working on scaling up what we do have, which means we’re stopping active development on Process Builder and Workflow Rules.
The best way for you to maintain and future-proof your organization is to move your automation to Flow. That can be a large, daunting task for those of you who have become Process Builder rockstars or are looking at a giant pile of Workflow Rules that nobody has touched in 3 years. We know this will take time.
Ok, so one day, you will not be able to create new Workflows, and Salesforce is encouraging us to migrate our existing Workflows over to Flows. So, how do we do that?
In this article, I’ll show you how to use HappySoup’s new Workflow migration tool, and Salto’s free product to help with the task at hand.
Don’t migrate, consolidate instead
Salesforce has released its official workflow migration tool, which creates a 1:1 mapping of a Workflow to a Flow.
So if you have a Workflow that has a field update, the tool will create a Flow that updates a field on the record that triggered the Flow.
This is a good start, but it’s not scalable. For example, if you have 20 Workflows on the Account object, using the tool would leave you with 20 Flows. That’s not any better; you just moved your mess from one room to another.
Ideally, we should look at those 20 Workflows and figure out how we can consolidate them into fewer Flows. For example, you could consolidate all field update Workflows into a single Flow called “Account updates,” where you use decision elements to decide which fields are updated.
This could make it easier to reason about your Flows. For example, you’d have one Flow for account updates, another one for email alerts, etc.
That’s just one example. You could also group Workflows based on common fields or common business processes and move them over to a single Flow.
Okay, that all sounds very nice, but how do I do that again?
HappySoup.io and Salto.io to the rescue
The idea of looking at 20 or more Workflows and figuring out how they are similar sounds great, but in practice, it’s really hard to do. You need to somehow export all the info about your Workflows and be able to sort them by the fields they are using in the criteria, which fields are being updated, etc.
When it comes to Process Builders, you need a way to quickly understand what they are doing and how they compare to existing Flows in the org.
HappySoup.io Workflow Export Tool
HappySoup.io is a 100% free and open-source application for Salesforce impact analysis. I recently added a new feature that allows you to export all your Workflows in a flattened format. This enables you to put them in an excel document and filter, sort, and organize them in whatever way you imagine.
As usual, an image (video in this case) speaks a thousand words, so please watch this video where I explain how this feature works.
Salto’s Free Product Flow and Process Builder Visualization
Salto.io has a 100% free tier with impact analysis capabilities, similar to HappySoup.io (and often better!).
The free product also allows you to visualize Process Builders and Flows in a brand new format. This makes it super easy to understand what the Process Builder is doing, which variables are being used, the actions/conditions, etc.
Again, an image speaks a thousand words, so here’s a video showing how it’s done:
With these two free tools, you now have a way to understand everything about what your workflows are doing and a way to visualize complex flows and process builders.
What’s left is to spend some time going through them and creating a document or a process diagram that maps out how all these automations will play nicely with each other.
Make sure to do a thorough regression testing (based on what you documented) to ensure you didn’t break any business processes along the way.
Do you have any ideas or insights on making this migration easier? Let me know in the comments!
I want to hear from you!
What is one thing you learned from this post? How do you envision applying this new knowledge in the real world? Feel free to share in the comments below.