Now is the time to migrate to Salesforce Flow®

Derek Vargas, Tom Hoffman
Now is the time to migrate to Salesforce Flow

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.


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.


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.


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.


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.


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.


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.

We are here to help

We believe in empowering others with knowledge, so the following contains the best of our flow design practices at Crowe.

Record triggered flow design patterns

We recently joined Salesforce’s “Automate This!” webinar series with a Salesforce Flow product manager, a Salesforce admin evangelist, and other "flownatics" to discuss how we moved forward in a Flow-only world.

The one-per-design pattern presented (and further documented here) is the standard for flow design at Crowe. It allows us to closely follow the trigger-handler-class pattern of Apex development and combines the best elements of scale, performance, and manageability – our guiding principles for Salesforce design. Our take on the one-per-design pattern is flexible and accommodates different business units and unique business processes, with an emphasis on keeping triggers minimal in following the “skinny control, fat model” pattern in software design.

Crowe services for migrating to Salesforce Flow

We know Salesforce Flow migration can be a lot of work, and already-limited Salesforce resources could use a hand tackling this initiative. Seriously, we get it. It took a team of six Crowe consultants three weeks to migrate all of our automation to Salesforce Flow internally, and this is sort of our jam.

Our flex innovation team at Crowe has put together a Salesforce Flow migration offering that allows you to engage our Crowe specialists in the manner that best supports your team. Check out the solutions below and drop us a line to learn more.


Have a Salesforce team and need ad hoc support for the measure, plan, and act phases of your migration to Flow? A Salesforce Flow migration block of hours is the perfect way to have our specialists available to jump in and supplement your team for design, training, building, or troubleshooting during your migration efforts to Salesforce Flow. Blocks begin at 25 hours.


Our team will work with your organization to complete the measure and plan phases of your Salesforce Flow migration, creating a detailed blueprint for your Salesforce team to implement our one-per-design pattern for all of your business process automation.


We’ll take it from here. Our flex innovation team will complete a detailed analysis and solution design for your business process automation, and then will get to work on completing your entire Salesforce Flow migration end to end based on the agreed-upon solution design produced during the plan phase.

Contact us

Regardless of the approach you select, your migration to Salesforce Flow will be in the hands of specialists using designs, standards, and practices that are leading-edge and shaping the direction of flow design in our industry.
Derek Vargas
Derek Vargas
Principal, Consulting
Tom Hoffman