In the past few years, we have been using Process Builder to automate business processes in Salesforce. This allows administrators, developers, consultants, architects even some advanced business users were able to create processes using process builder.
Now things are going to change as you may hear Salesforce announce “Go with the Flow: What’s Happening with Workflow Rules and Process Builder?” a must-read blog by no other than Jennifer Lee.
In this article, I will discuss the following topics:
- My point of view on why Salesforce is moving away from process builder.
- How you can prepare for it.
Salesforce Flow – A Revolution in Business Process Automation
I heavily worked on Service Cloud and Field Service Lightning in the past few years and created so many processes using Process Builder. If you ask me, does it make sense to move from process Builder to Flow?
My answer is gonna be yes; it does make sense. Let me add some comparison between these two products to prove my points:
| Process Builder | Salesforce Flow |
|---|---|
| A process only fires when the record is created or updated. | A flow can fire when the record is created, updated, or even deleted. |
| Process fire after a record is saved to the database. | Flow can fire before or after a record is saved to the database. |
| Only a limited set of objects are exposed to the process builder. | A large set of objects are exposed to flow. For example, AccountShare EventBusSubscriber GroupMember PermissionSetGroup And many more. |
| It does return a newly created record Id. | It does return a newly created record Id. |
| It doesn’t handle complex logic like counting related records and updating them on the parent record. | It has the ability to write complex logic when it comes to handling business processes using Loop and bulk updates. |
| It doesn’t have the ability to delete record(s). | It does have the ability to delete record(s). |
| No option to sort the record and only store the top 5 or top 10 records. | It can sort the records using Collection Sort and hold a specified number of records. |
| No option to Run Asynchronously | Ability to Run Asynchronously |
| We often create multiple processes per object. | It better fits with the “One Flow” framework by implementing Flow design patterns. |
| N/A | Ability to take user input and then write custom logic to process it |
| It only supports Time-dependent action. | It can schedule a job that runs at a specified time to handle business logic. For example, create a job that runs every night to create a task if the opportunity is open and doesn’t have an open task. |
| And many more |
I think the above comparison table gave you an idea of why Salesforce Flow is more powerful when we compare it with Process Builder. Rather than having multiple automation tools, it is best to have an automation tool to manage all automations.
How to Prepare for Migration to Salesforce Flow
When it comes to preparing to migrate on new tools or systems, you want to be as knowledgeable as possible so that you can design or create an implementation strategy for your company.
“We’re working on a migration tool that would automatically convert a workflow rule into a flow. That should be coming out early next year, with plans to add Process Builder migration as a follow-on.” – Quote from Salesforce Offical blog.
Salesforce is going to come out with tools that will help you to migrate workflow rules and processes to Salesforce Flow easily, but at the same time, you can do the following things to expedite this such migration on your own:
Take one object at a time
When you start something new, you can’t do everything all at once and expect the journey to be over; we can do one thing at a time. The same logic applies here as well; it gonna a longer, lengthier, and more exhausting process if you try to migrate all processes from all objects to Salesforce Flow at once.
Based on my experience, start with an object and try to migrate all workflow rules and processes to Salesforce flow. At the same time, create a learning sheet where you can jot down your mistakes, learning, or finding so that you will not do the same mistake next time.
Understand the business processes
Once you decide on the object and create your learning sheet, the next step is to understand the business processes. This is the right time to sit with your business stakeholders for an hour or so on the following:
- Gather feedback on what is not working.
- Identify the area for improvement or potential new automation (New automation scope that may help them achieve their matrix).
- Identity the automation which is no longer needed.
- Make sure to capture all this feedbacks in Agile tools like Trello, Azure, etc, so that you can track the process for it.
Create a process flow diagram
After you understand the business processes and the new requirements, it is the right time to create a process flow diagram and validate it with the business. Take this opportunity to improve the user experience, as well as help businesses achieve their goals.
A process flow diagram is a flowchart that illustrates the sequence of steps needed to complete a business process.
Work with your architect or consultant to validate your design
Once you’re done with the process flow diagram, the next step is to design. Means what kind of flow are we going to use? Is it Before Save or After Save? Or even a Schedule FLow? Do we also need Subflow to handle a reusable piece of work better?
If you have an architect in your company or circle, do validate with them as the design is the stepping milestone for this transition. I am a few Trailhead modules here for your to learn flow best practices.
→ Make sure to update your learning sheet daily so that the next time you do the same exercise for another object, it will be much easier for you.
Spinup a new sandbox
Once you’re ready to build, take a deep breath and pat on your back; you’ve learned a lot. Now it’s time to do the real work. The question is, where are we going to do this work? Production???? Obviously Yes?? NO DON’T.
Create a new Sandbox and start building the Flows there as you don’t want to mess up with your real data.
Deactivate the Old Automation and Test Flows
As you’re now done with Flow and ready to test, take a minute pause and deactivate all processes and workflow rules from the object.
As we have written down all the scenarios in Trello, go ahead and start testing and make sure to validate the outcomes.
→ Make sure to update your learning sheet daily so that the next time you do the same exercise for another object is gonna be much easier for you.
Deploy the Flow(s) and detective process builder in the production
Ready to deploy your newly created Flows. What a relief? I know, I know, I had the same feeling whenever I deploy new stuff.
Go ahead, use Change Set, Package, or even Visual Studio Code to deploy your Flows to production.
Repeat the above steps for other objects
Now it’s time to review your learning sheet. Review what you can do better for the next object workflow rules and processes migration.
Go ahead, identify another low-handing object, and repeat the above steps. You’re now a Process Builder migration expert.
If you need any help in Process Builder to Salesforce Flow migration, feel free to reach out to me.
You are done!
I want to hear from you! What did you learn from this post? Share your tips in the comments!
Great Post! I did not know how to start this migration process effectively. Thanks a lot for writing this!!
I am happy you like it!