Originally published on LinkedIn.
Salesforce announced late in 2021 that workflow rules and the Process Builder would be added to the retirement calendar (calm down, everything you need to know is here). If you've been following the release notes for the last year or so, you noticed that the Salesforce engineering team has put a huge focus on updating the Flow Builder. This announcement is the final endorsement of Flow Builder as the Salesforce automation tool of the future.
While Jennifer Lee's awesome article above answers a lot of the technical questions, this announcement sparked a series of conversations amongst the Slalom LA Salesforce team around what this means as Salesforce Designers and Architects: Do we have to redesign everything? Will Salesforce move stuff over for us? How do we prepare our clients for this change?
In case you didn't read the article, open it in a new tab. My article is supplemental to Jennifer's and won't make full sense without that context. That said, Salesforce is creating a migration tool to move over Workflows and Process Builders to Flows. Those tools are still under development so details are sparse but we know they're coming. This begs another question among consultants, though: Does it make sense to just migrate everything over or is this an opportunity to tighten up the automation structure overall? More on that in a second.
It's important to know that there's a lot of runway before this reaches our doorsteps. Here's the timeline as we know it:
Spring 2022: Workflow migration tool begins release.
Summer 2022: Process Builder migration tool begins release.
Late 2022: Turn off create new buttons on workflow rules and Process Builders. Existing workflow rules and Processes will run as expected, while being migrated to Flows.
While the switch won't happen for some months, it's never too early to start conversations around this. Especially because, depending on the web of automation you've built in your org, it may take a significant amount of that time to redesign, rebuild, test, train and deploy those changes to your user base.
As you weigh the impact of this decision on your org and company, here's some advice from the Slalom LA Salesforce team on things to consider:
Documentation
If you haven't already, start documenting your automation. I recommend a diagram with swim lanes for each type of automation you're using (workflow rules, approval processes, Process Builder, APEX Triggers and Flows). If possible, I recommend swim lanes along the other axis representing your different user groups. If that's too much for your first draft, do them separately and then combine. Ultimately, this exercise will result in you having the automation part of a configuration workbook. If you already have a configuration workbook with automation, then you're ready to move on to staffing.
Staffing Resources
There are many staffing and resource considerations to be made throughout this process, as well. First, use your configuration workbook to identify which user groups are using automation. From there, determine which individuals will need to play key roles in the review stage. Also, make sure to consider the demand on your technical resources. Depending on the scope, a project of this scale may take the people with the rare technical skills away from other company projects. Make sure that your technological roadmap will be supported and plan accordingly.
Consolidation Review
Once you know who to involve and what automation effects their job roles, you're ready to review everything and determine, feature by feature, 1) whether it can safely be migrated using Salesforce's not-yet-completed migration tool, 2) whether it needs to be updated to better leverage the Flow designer's capabilities, and 3) if it needs to be consolidated with other rules now that Flows can handle that level of complexity. Once you've categorized each feature, then fold them into your current DevOps process to prioritize and fit these into your roadmap.
Flow Best Practices
There was a time when it was best practice to only have one Flow per object inside Salesforce. Now that Flows have grown in functionality, that best practice no longer applies, and there's a pretty awesome reason why. When setting up a record-triggered Flow, admins must configure whether the Flow runs only on creation, only on updates, on creation and updates, or upon deletion. This means that, depending on your desired order of execution, there could very well be a scenario where one object needs a flow upon creation (to set default values) and also a Flow that fires for all updates that reevaluates the record and determines the Status, for example.
Combining the new functionality with the old best practice yields us the following, new best practice: no single Salesforce object should have more than four (4) flows. However, within a single Flow, you may have automation that used to be three (3) Workflow Rules and a Process Builder.
Why Flows?
So now you may be asking yourself, why Flows? Why do we have to go through all this effort to move everything to Flows? Is it really that much better? The answer is yes.
As you can see in the theoretical scenario above, a single Flow can be configured where multiple workflow rules or process builders were required before. So this creates a single place in Salesforce to configure declarative automation. Anyone who has ever had to try to reverse engineer a previous Salesforce admin or developers work and unravel their web of automation can see the clear benefits to having all of that in one place.
Also, Flows are incredibly robust and can even replicate APEX functionality in some cases with Loops and collection variables and the like. In short, you could design all the automation in your system from one place, and you wouldn't need a developer to build it out. Just a good admin that's comfortable with Flow.
If you're having trouble with this transition and need to speak with a Salesforce expert, the team here at Slalom would be happy to steer you in the right direction. Just inbox me to start the process.