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:

• The vast majority of workflow rules (WFRs) are used to send email alerts and perform same-record field updates. While WFRs have a reputation for being fast, in system performance measurement we saw they’re considerably slower and more resource-hungry than a single functionality equivalent to a before-save flow trigger.
• Process Builder runs on top of Flow’s runtime, but there’s a significant difference between Process Builder’s user-facing design-time model and Flow’s runtime metadata model. This abstraction results in a process’s underlying metadata resolving to a mangled, less-performant, and often incomprehensible Flow definition. A mangled Flow definition is much harder to debug than a non-mangled Flow definition.
• In addition to the shortcomings already mentioned, both processes and WFRs depend on a highly inefficient initialization phase that drives processing time up across every save-order execution they’re in.
• When reviewed from a processing standpoint, the majority of processes and WFRs resolved to a no-op at runtime. This means when the criteria weren’t met, operations were not performed. In those cases, we spent the system resources to trigger the automation, but we didn’t materially benefit from the initialization phase.

Prepare for the migration

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:

• Review the business processes and rules that correspond to automation processes in Salesforce. Make sure there are no glitches or dead ends in the process. You can use Lucidchart or a similar tool to visually represent these processes so it’s easier to detect bottlenecks and identify opportunities for improvements. For example, if you’re documenting your support process, start with all the ways a case can be created. Document the whole case lifecycle until the case is closed, including the actions that might follow, such as creating a Knowledge article.

• Once you have your process map in place, update it by mapping the declarative automation to each stage of the process. This is also a good opportunity to identify WFRs and processes that might be inactive, outdated, or obsolete. You can update or remove and not include them in the transition, lowering the technical debt in the org. This mapping exercise is also useful for determining context in which the new flows will run. For instance, if we have WFRs sending email alerts on a case update, we can easily determine the flow(s) that will replace them and have to run in the after-save context.
• It’s important to take time to plan and design your automation processes, making sure to follow the business rules and avoid creating new technical debt along the way. Resist the desire to fire up Flow Builder and create a new flow before you have the holistic view of the automation on the object. Instead, use a tool like Lucidchart or even text editor to design your new flow, outlining all the information you need. You’ll use this information to translate those guidelines into flow actions and variables later.

Design the solution

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:

• Migration from WFRs to flows is not 1-to-1. It would be a bad solution to create a new flow for each WFR. You won’t be able to scale up or easily maintain or upgrade the process.
• Analyze existing flows to see if there are corresponding elements that you can update or incorporate new actions in an existing flow (this is where that mapping diagram will come in handy).
• Consider whether the more complex automation processes can be reused and implemented as subflows.
• Review whether there’s a more optimized solution that doesn’t involve automation. For instance, if your WFR is just updating a field on the Case object after it’s created by copying value from the related Account record, consider replacing it with a formula field instead.
• For those WFRs that can’t be incorporated into existing automation, review how you’re going to move them to Flow. Test the new Salesforce migration tool or try building a flow from scratch.

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.

• Most of the time, WFRs are used to implement same-record field updates. To optimize the automation performance and avoid risk of recursion, these should be migrated and implemented in before-save flows.
• If there are updates to the related record or an email alert is being sent, then the possible business logic should be implemented in an after-save flow.
• Automation with highly complex implementation logic or one that implements multiple loops will require high-performance batch processing. Your best bet in these cases is to use a combination of a flow with invocable Apex and let the code handle the complex calculations.
• For automated processes that require implementing scheduled actions or multiple record updates, the business logic should be implemented using a scheduled path in Flow while also adjusting batch size to avoid hitting per transaction Apex limits.
• If the process is too complex and involves branching logic, it might be a good idea to introduce subflows for each of the processes and use a master flow to invoke them.

Migrate workflow rules to Flow

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.

Migrate processes to Flow

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.

Consider subflows

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:

• They’re not available in record-triggered before-save flows.
• Debugging can be tricky and could be improved with error screens.
• There can be some overhead since subflows have to be defined as standalone flows, so we have to be careful to not overdo it.

Summary

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:

• Add fault paths with error handle screens or an email alert that will send a notification about an error message.
• Build unit tests to confirm our flow is working even after updates. If you’re skilled with Apex, you can build tests yourself. The Salesforce Automation team is working on creating automated testing for flows.
• Use debug logs to understand why a flow failed and what might be the root cause.
• Remove any hard coding that’s common in WFRs and processes, and replace hard-coded IDs with custom labels, custom settings, or custom metadata.

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.

Resources

• Salesforce Admins Blog: Go with the Flow: What’s Happening with Workflow Rules and Process Builder?
• Salesforce Admins Video: Use Flow Trigger Explorer to Easily View All of Your Record-Triggered Flows
• Salesforce Admins Blog: Your Guide to Determining the Flow Running User and Its Execution Context
• Salesforce Admins Blog: New and Updated Flow Resources to Make Your Life Easier
• Salesforce Admins Site: Automation
• Trailhead: Flow Builder
• Trailhead: Formulas and Validations
• Trailhead: Build Flows with Flow Builder
• Trailhead: Record-Triggered Flows
• Trailhead: Build a Discount Calculator

Want to see more good stuff? Subscribe to our channel!

SUBSCRIBE TODAY