Salesforce Workflow Rules and Process Builder have been the standard no-code automation tools organizations have relied on for years to create efficiency in their business processes. Salesforce sent a shock through the ecosystem last year when it announced that both Workflow Rules and Process Builder were scheduled for full-feature retirement and that Salesforce Flow would be the only Salesforce automation option moving forward.
Salesforce historically has announced target end dates for feature retirement and critical update enforcement and later backed away from those dates; however the retiring of Workflow Rules and Processes is moving ahead according to the schedule outlined in May 2022.
As of Oct. 15, 2022, the ability to create new rules in Workflow Rules was terminated, and looking ahead to February 2023, the ability to create new Process Builder processes will be unavailable as well.
It is easy for an organization to feel overwhelmed as it reflects on the years it used Workflow Rules and Processes, especially considering the time and effort involved in migrating to Salesforce Flow. It can help to understand why this change is happening.
Why retire Workflow Rules and Process Builder?
When Workflow Rules and Process Builder were introduced, they represented tremendous innovations and transformed how organizations built and designed for the platform. Just like how automobile infotainment systems from 2015 have aged poorly compared to those in later-model vehicles, these tools have passed their prime as the demands of Salesforce customers have increased.
Scalability
Workflow Rules and Process Builder always have been challenging to manage with even minimal organizational complexity. An organization could have 30 rules that all do the same function, for example: "based on one of 30 picklist values set on an account record, populate a corresponding value on the account."
Given the same requirements (based on one of 30 values being present, set a corresponding value) a similar number of Process Builder nodes would need to be used or a 32-line CASE() formula used on the update action. Any changes in either value set require an edit to the automation.
Salesforce Flow provides the ability to build this in a more scalable, less resource-intensive way. The user is able to create a custom metadata type (CMDT) that maps the possible record values to corresponding values that need to be populated. When a value is set on the record, the Flow refers to the CMDT for the correct value and sets it; it is three boxes on a Flow landscape and future updates only require changes to the CMDT table that maps values to each other.
Using proper flow design standards, bulky Workflow Rules and Process Builder operations can be greatly simplified, grouped, and ready for the most demanding sizes and scales of business.
Performance
Workflow rules individually are fast, however field updates cause the order of execution to be partially rerun; meaning for each rule, recursive saves actually make it quite resource-intensive.
Process Builder is the slowest of automation options, partly because of the UI layer involved and largely due to the resulting flow interview that includes redundancy with all of the “My Decision,” “My Outcome” language.
Before-save trigger flows are incredibly efficient (nearly as fast as before trigger apex), and well-structured after-save trigger flows operate at speeds three to four times that of Process Builder.
Manageability
Workflow rules become unwieldy overtime, as they can only handle a single set of criteria before executing actions. It is not uncommon to see pages and pages of rules in legacy organizations. The same is true for Process Builder – but it’s worse. The user interface for Process Builder is slow and aggravating with just a single process, and as it scales to multiple pages, managing processes becomes quite a chore.
Using a well-structured flow design pattern and object-oriented list views, managing flows becomes an administrative-friendly task. Salesforce Flow Trigger Explorer allows a user to see all triggers on a specific object and have further control over the order of execution as well.
A Flow-only world
For organizations that have not completed their migration to Salesforce Flow, the time for action is now, while there is time to measure, plan, and act intentionally. The risk in waiting is too great, as companies eventually will be backed into a corner with the retirement schedule highlighted above.
The actions that follow can help organizations meet the demands ahead.
Measure
To start, document all workflow rules and processes by object. Capture the criteria and related actions to get a complete picture of the automation associated with creating and updating each object. Now also is a great time to revisit these automations with business stakeholders to validate their relevancy and remove any automation that no longer is needed.
Once the documentation is done, create a final list of requirements by object – both the criteria and the actions to take place – to have a complete view of automation that needs to be migrated to Salesforce Flow per each object.
Plan
Use a visual mapping tool to draw out the organization’s flows using a record trigger flow design pattern that fits the business's needs.
Work through the object requirements created during the measure phase and draw out the before-and-after save automation flows for each object, crossing off the requirements and actions as they’re mapped. Validate that all requirements and actions are satisfied in the models, prioritize the critical automations and processes, create time estimates for each, and assign team members to begin executing the plan.
Act
Directly in production, begin to create new flows to replace all legacy Workflow Rules and Process Builder elements. Begin executing the new plan by promoting the automation associated with each business process to user acceptance testing environments for testing before deploying to production. Using an iterative, continuous deployment approach versus a "big bang" approach will help with regression testing and prioritizing critical functionality over less-important elements.
