Kisha Gulley was once kicked out of a Facebook group for mothers with autistic children after a c...Read More
It was a love story from the beginning: An admin needed to automate a simple process, and Workflow Rules offered its simple and intuitive user interface as a solution. However, as process complexity grew, admins started to incorporate Process Builder as well, admiring Flow from a safe distance or carefully dipping their toes in to play with it. As Flow added more functionality over the years and introduced different context and time-scheduled actions, it became the most powerful declarative automation tool and gained more attraction and support. On Trailblazer blogs and in community conference sessions, we learned how many common business problems can be automated using Flow. It quickly became a tool that empowered admins and turned them into fearless problem solvers, or Flownatics as we like to call them.
With Flow being the most powerful declarative automation tool, and having all the functionality of Workflow Rules and Process Builder but better performance, it was a logical step for Salesforce to announce unification of declarative tools by gradually sunsetting Workflow Rules and Process Builder and moving all automation to Flow.
According to the announcement made at Dreamforce '21, Workflow Rules and Process Builder will be retired by 2023. And, in order to prevent further creation of technical debt, we should only focus on creating new flows. Technical debt is a concept that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of a better approach that would take longer. If tech debt is not addressed, it can possibly make it harder to implement changes or cost more to address them in the future. If you're wondering why you should migrate to Flow, here are some important things to consider:
As for existing WFRs and processes, Salesforce is helping us transition with the new Migrate to Flow tool. Despite its limitations, it’s a great tool to start with. But before we fire up the new tool, we need to determine the strategy and approach for this migration. We already know that we’ll have to start this process in a sandbox and perform extensive testing of all automation we’ll touch.
Here are the steps to take to help you prepare for the migration:
When deciding on what your end solution will look like, remember that you may be building more than one flow. Before you start building your automation, consider the following in designing it:
It’s not an easy decision of how and where to migrate WFRs and processes, and there’s no one-solution-fits-all approach. Here’s a useful logic to follow when deciding on which automation tool to use:
As you can see from the decision graph above, there’s clear logic when it comes to deciding which solution to use.
As we mentioned, Salesforce is helping us adopt Flow on our way forward with the Migrate to Flow tool. This is currently available in sandboxes and production environments. Please remember that you should test this in a sandbox first.
The migration tool is intuitive and user-friendly. To access it, you just need to search for it in the Setup menu. You’ll see the list of all WFRs; click on the one you want to be migrated and select Migrate to Flow. Once the new flow is created, it’s going to be inactive and you can preview it before the activation. Clicking the Activate button will ensure the new flow becomes active while deactivating the WFR at the same time.
If the update happening through the workflow is independent from other processes, that means we can replace it with an independent flow, and we can utilize this tool for quick migration. This is what the original WFR looked like:
Notice how the corresponding flow looks clearer and much easier to understand just from this first glance.
We see that this process should run only when a Case record is created or updated to meet certain criteria. If “Debooked Deal” and “Follow up with support engineer” checkboxes are checked, then both the Status and Update Accepted Date fields should be updated as well. This is a quick action update so we can use a flow optimized for fast field updates.
However, if you notice there are connected actions in a WFR that are happening under the similar conditions, you can combine them into one flow using a Decision element. Let’s say you have multiple WFRs that send different email alerts on case creation based on the product that’s connected to the Case record. Back when Flow didn’t have the email alert action, it made sense to create numerous WFRs for each of these scenarios. Today, we can convert and combine them into one elegant flow that will be created as an autolaunched flow after the case is created. Instead of triggering each WFR and checking the criteria, we can trigger one flow that goes through a single Decision element and sends the email alert based on the specific choice.
Salesforce has not provided a tool that can help us migrate processes yet, but this is on the near-term roadmap. Similar to what we discussed in converting WFRs to Flow, you need to make a plan and decide on the end solution. With processes, we have the option to convert every process to Flow, or for ones with complex actions, we can create a new flow out of every decision point. For simple processes that have similar triggers, we can even combine two processes into one flow. Let’s consider that approach.
In our example, we have two processes that are happening on the Case object. The first process is making simple updates to a field on a case when the record either gets created with P1 priority or gets updated to P1 level. The second one is triggered when a case’s priority is being updated to P1 and if there was a notification sent to the Exec Sponsor. As a result, it captures the email of the support agent and the email of his manager in corresponding fields. If we visualize these two processes, we can see how these two can be combined into one flow.
Here’s the visual representation of these processes:
After we combine these two processes, the final automation solution is a record-triggered before-save flow that will handle both of these changes at the same time. This means we’ll initialize one automation process and save system resources, while streamlining a process and making it easier to understand and debug.
If your process has scheduled actions, those can be tricky to combine with other elements because a scheduled path in the flow can only be defined on the Start element. This might be a good case for breaking a process into multiple flows, where one handles the scheduled actions and the other updates fields that might impact the scheduling. Considering that Salesforce Architects are now suggesting we don’t have to follow the one flow per object approach anymore, this might be a much better, more scalable solution. Instead of building one big flow and worrying about scheduling actions, we can now build multiple flows per object and control the order of execution with a shiny, new feature called trigger ordering.
In our next example, we have a process that runs on case creation and updates the related Contact record’s “Do not contact” field so the customer doesn’t get spammed while the initial updates are happening. The same process also updates different fields on the Opportunity, depending on the information from the newly created Case record—and it has a scheduled action at the end to uncheck that “Do not contact” field on a related Contact after 5 minutes. If we look at the actions included in this process, we can easily conclude that it would be best to separate this action into two flows: one that will update the related Contact record and has a scheduled path, and another that will update the related Opportunity.
So, we can split this process into a flow that updates the Opportunity and looks like this:
We can then create a separate flow that updates the related Contact record with the scheduled path.
This way, we have better control over the updates, and both flows are easier to troubleshoot and debug. Equally important is that these flows are now scalable with the new criteria and will simplify maintenance, meaning it will decrease the risk of creating technical debt.
Subflows are a good way to handle separate business processes and make them easier to maintain and update. They’re also a convenient way to build reusable automation processes, so they can be called multiple times when needed in the same flow or used in another flow as well. #WorkSmartNotHard. Subflows also help simplify automation of processes that are complex and involve branching logic. It might be a good idea to have one master flow that will invoke subflows for each of the processes, saving the performance resources from unnecessary initialization.
Another good use of subflows is if there’s a need for context change. We might have a master flow that’s running in user context, but we need a subflow to update records or perform an operation the user doesn’t have access to. We can easily solve this by setting a subflow to run in system context.
There are few caveats when it comes to using subflows:
WFRs and processes have been with us for a long time, and most admins are very comfortable using them to the point that they might have not fully embraced the flow. However, Flow is the future of Salesforce automation, and with new migration tools announced, we should look into getting more familiar and comfortable with building flows. The best way to start is to review business processes in Production and document all the automation processes happening to be ready to start working on changes when the timing is right.
Also, as we migrate more to Flow, we can add extra steps to help with potential issues:
Now that you have these guidelines, it’s time to start your journey to Flow. Let us know in the comments of the YouTube video what your plan is for this expected migration.