Retire Workflow Rules and Process Builder - Flow in Action to migrate

💡 Why there is a need to migrate in to flow !!! 😒

✔️ Workflow rules (WFR) are majorly used to send email alerts and perform same-record field updates. To perform faster WFR execute repetitive manner, and its significantly reduce the system performance and more resource-hungry than a single functionality equivalent to a before-save flow trigger.

✔️ 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.

✔️ Process Builder (PB) runs on top of Flow’s runtime, but there’s a significant difference between PB’s user-facing design-time model and Flow’s runtime metadata model. This abstraction results in a process’s underlying metadata resolving to a twist, less-performant, and often incomprehensible Flow definition. A twisted Flow definition is much harder to debug than a non-mangled Flow definition.

✔️ In case of WFRs or PBs, when 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. Its critical in processing standpoint.

💡 Get Ready for Migration …

As for existing WFRs and PBs, Salesforce is helping us on transition with the new Migration tool. Regardless of its limitations, it’s a great tool to start with. But before we jump into 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 migrate or modify.

💦 Some steps we may follow to prepare for the migration:

⚡ Review the business processes and rules that correspond to automation processes in Salesforce. Make sure there are no hiccups or dead ends in the process. Visually represent these processes properly so it’s easier to detect blockages and identify opportunities for improvements.

⚡ Once you have your process map ready, mapped it with declarative automation in each stage of the process. Here you can get a scope to identify WFRs and processes that might be inactive, outdated, or obsolete. You can update or remove them and not include in flow transition. This mapping exercise is also useful for determining context in which the new flows will run and help a lot in implementation.

⚡ It’s important to take time to plan and design your automation processes, make it confirm to follow the actual business rules and avoid creating new technical liability along the way. Resist the desire to fire up Flow Builder before creating a new flow to have the holistic view of the automation on the object. Try to represent the new flow in any design diagram before implementing it and outlining all the information you need. It will be a good option to use that information as an input at the time of implementation of new flow.

💡 Design the solution:

When you decide to prepare the solution, keep it mind there can be some sub flow / or more than one flow will help you to build entire solution. You can consider the following in designing a automation solution with flow on top of WF/PB:

⚡ Migration from WFRs to flows is not blindly 1:1. It would be a bad solution to create a new flow for each WFR. Overall perspective it 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 (you can refer the mapping doc here).

⚡ Consider sub-flow whether the more complex automation processes can be reused

⚡ Review whether there’s a more optimized solution that doesn’t involve automation. For instance, if your WFR is just updating a field in an object after record created by copying value from the related other object’s record, you can consider formula field instead of any other automation.

⚡ For those WFs that can’t be incorporated into existing automation, review how you’re going to move them to Flow. With the help of Salesforce migration tool test the flow or try building a flow from scratch.

It’s not an easy decision of how and where to migrate WFs and PBs, and there’s no one-solution-fits-all approach.

💦 Let’s consider a logic flow to decide on which automation tool to use:

💡 Migrate workflow rules to Flow

Salesforce is helping us on transition in Flow 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.

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. But

The migration tool is still in Beta phase as mentioned by salesforce. After conversion, the new flow needs manual intervention and thorough testing. Currently the tool unable to update the fields based on the formula that uses time/date. This also doesn’t implement time-based email trigger.

💡 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 below 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.

💡 Significance of "Sub-flows"

Subflows are a good way to handle separate business processes and make them easier to maintain and update. To make complex business process isolated, sub flow helps significantly. To build reusable automation processes, Subflow is a best option in salesforce automation, so they can be called multiple times like components when needed in the same flow or used in another flow as well. Subflows also help simplify automation of processes that are complex and involve branching logic with control flow. It might be a good idea to have one master flow that will invoke subflows for each of the processes, it also save 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 limitations when it comes to using Sub-flows:

✔️ They’re not available in record-triggered before-save flows.

✔️ Debugging can be tricky and could be manage through 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.

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.

💦 Some best practice to deal with any potential issues in flow:

✔️ Add fault paths with error handle screens or an email alert that will send a notification about an error message.

✔️ Automated Testing on flow still not available, Salesforce Automation team is working on creating automated testing for flows. So build unit tests to confirm your flow is working even after updates. You can also build tests Apex.

✔️ Use debug logs to understand.

✔️ Don’t use any hard coded IDs, or common text replace hard-coded IDs with custom labels, custom settings, or custom metadata.

Ref: Salesforce Admins.