(Part 1 of 5)

It’s Transition to Flow time!

Salesforce is retiring Workflow rules and Process Builder in the near future. The time to start planning to move your Salesforce automations to Flow is now. In this series of articles, I will explain why this change is occurring, what you need to do and I will even provide you with a plan to migrate all your workflows and Process Builder to Flow.

Here’s why you need to act now:

1. Process Builder and Workflow Rules are being retired.
2. Flow is now the preferred automation tool for Salesforce.
3. Flow functionality has surpassed Process Builder and Workflow Rules.
4. Process Builder performance is poor, Workflow Rules can be resource hungry.
5. Low-code/no-code applications are expected to rise to 70% in 2025.

Process Builder and Workflow Rules are being retired

Salesforce has been hinting for about the last 12 months that the end is near for both Process Builder and Workflows. There have been announcements at DreamTX, the Admins Release Readiness webinar for Winter ’22 and more recently at Dreamforce ’21.

Diana Jaffe, Flow Product Manager at Salesforce: In the Admins Release Readiness webinar for Winter 22 (on 11 Sept, 2021), had this to say:

As we move forward over the next year, we will begin to retire workflow rules and process builder. As well as continue to add more functionality to Flow.

Diana Jaffe

No more investment is being made in Process Builder or Workflows. This means no new features and they will only get some love if something breaks or there is a security issue.

Commencing with the Winter ’23 release (Sept/Oct 2022), the ability to create new Process Builders or Workflows will be blocked. You will still be able to edit existing processes and workflows, just not create new ones.

Note: These dates are forward-looking and subject to change, depending on community input and the ability to deliver the required tools and support services.

Regardless of whether the end date is late 2022 or pushed back even later, the intention is to retire these products in favour of Flow.

While there is no rush to get rid of all your Workflow Rules and Process Builders immediately, you do need to plan for this in the next 12-24 months. If you have a large org with a lot of WFR and PB (we can now call them technical debt), then the sooner you start this journey the better.

Flow is now the preferred automation tool for Salesforce

On the Salesforce Architects website they specify:

With the release of before-save Flow triggers in Spring ’20 and after-save Flow triggers in Summer ‘20, we officially recommend Flow and Apex as the preferred no-code and pro-code options for triggered automation on the platform.

Salesforce Architects

They also state:

• Takeaway #1: Stop putting same-record field updates into Workflow Rules and Process Builder. Start putting same-record field updates into before-save Flow triggers instead.
• Takeaway #2: Wherever possible, start implementing use cases in after-save Flow triggers rather than in Process Builder and Workflow (except for same-record field updates, in which case see point #1).
• Takeaway #3: If you have high performance batch processing needs or expect highly sophisticated implementation logic, use Apex.

Salesforce is positioning Flow as the cornerstone of automation tools for the platform and in the September 2021 Magic Quadrant report, Gartner notes that:

The Salesforce platform has a fragmented approach to supporting logic and workflow. The enhanced Salesforce Flow tool is at the core of its approach, but Einstein Automate is a loose collection of tools, including Einstein bots, industry workflows from Vlocity Omni Script and add-ons in AppExchange.

Gartner Group

It is reasonable to expect that there will be more consolidation and integration of the automation capabilities of Flow, Einstein and Vlocity tools. It appears that these tools will be collectively known as Einstein Automate.

Flow functionality has now surpassed Process Builder and Workflow Rules

Not only can you now do everything in Flow that was possible in Workflow and Process Builder, you also get these awesome benefits too:

• Better all-round performance with before save Record Triggered Flows being very close to the performance of Apex triggers.
• Better error handling, troubleshooting and debugging capabilities.
• Extensibility with Invocable Actions that allow you to easily call Apex when you need to perform some heavy lifting in your flow.
• Access to future developments including Next Best Action and Flow Orchestrator.

Workflow Rules can be resource hungry

While workflow rules are fast, they can be resource hungry and will not benefit to improvements being made to flow. Salesforce Architects explain more here.

The vast, vast majority of Workflow Rules are used to perform same-record field updates. While Workflow Rules have a reputation for being fast, they nevertheless cause a recursive save and will always be considerably slower and more resource-hungry than a single functionally equivalent before-save Flow trigger.

Additionally, Workflow Rules are just a completely different system than Flow — different metadata, different runtime. Any improvements we make to Flow — not just performance improvements, but debugging improvements, manageability improvements, CI/CD improvements, etc. — will never benefit Workflow Rules, and vice versa.

Salesforce Architects

Process Builder Performance is Poor

What makes Process Builder so bad?

In this article by Salesforce MVP Narender Singh, he mentions the following four reasons for this poor performance:

• Record Updates to the same record cost one SOQL Query and a DML in Process Builder (effectively an after-save flow); where flow has a before-save feature that is much more efficient.
• Cross Object Updates done in flow can avoid the SOQL query for parent records and for child records, the bulkification is handled better in flow.
• Recursion: where the process is run again if the previous update causes the process to be run gain is in his opinion one of the main reasons why transactions using Process Builder are slow. Flow does not support this recursion, avoiding this problem.
• Overall Performance: The runtime design of process builder is inefficient.

Salesforce Architects, in their article about Record-Triggered Automation, uncover some of the underlying reasons for this poor performance:

Process Builder runs on top of Flow’s runtime, but there is a significant difference between Process Builder’s user-facing design-time model and the Flow runtime’s 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 will be much harder to debug than a non-mangled Flow definition.

Salesforce Architects

The rise in Low-code / no-code applications

According to the respected Gartner Group, low-code/no-code applications are expected to rise from 25% in 2020 to 70% in 2025. Read more about this story here:

https://www.gartner.com/doc/reprints?id=1-27I1GT39&ct=210921&st=sb

Making Salesforce Easy

From the True To the Core session at Dreamforce, reported via Salesforce Ben and others, there was a recognition that Salesforce needed to change from just adding more and more tools to the environment and to begin to consolidate tools to make life easier – they used the phrase “Salesforce Easy”.

Part of the reasoning for retiring Workflow Rules and Process Builder was to meet this direction and to consolidate support and development around a single automation product.

Admin Support for Flows

Mark Jones (customer) asked the True to the Core session at Dreamforce ’21 the following question about support for flow when a case is raised with Salesforce:

As we go through support and we try to get help, often like Flow we’re told well that’s a Developer challenge, you have to have Developer support. It now is an Admin even under Admin certification and yet it’s a year away from being prioritised to be included in the support package. New features aren’t coming out in support that are beneficial, like macros and other things. So how can challenges that take years like that be escalated and solved faster for customers. Because I can’t advocate for Flow to be an Admin tool if Admins can’t get support.

Bret Taylor (Salesforce President and COO) made a commitment to investigate the issue and responded later in the day with this message on Twitter to confirm that support will be extended to include flow:

Still need convincing?

David K. Lui, Salesforce Technical Architect at Google and 8 x MVP is firmly in favour of the transition to flow:

Jen W Lee the original (and best) “Flownatic”, now an Admin Evangelist at Salesforce says:

In the Behind the Automate Apps Fast for #AwesomeAdmins Dreamforce Episode, Jennifer also stated:

I would say definitely for admins out there who’ve been scared of using Flow Builder, now is the time to start using it, to build all of your automation, forget about workflow rules and process builder, really dive into that because Flow is like all over the place. You see it with Flow Orchestrator, it’s just growing and growing and you’ll start really thinking if you haven’t done automation, think about ways to automate your business processes, make life better for your users, make it more productive.

Jennifer W Lee

Ok How do I get there?

Thought you’d never ask!

In the next article, I will dig into the details of your flow transition plan.

You can get started on your Flow training here:

www.CertifyCRM.com

Next>> Part 2