It Is Time To Go With The Flow

Throughout its history, Salesforce has rarely made decisions that will fundamentally alter the landscape of existing Salesforce org configurations.  This predictability has been part of their basic ethos – Salesforce will provide access to their flexible and secure state-of-the-art platform while the rest is up to the customer.  The customer will have access to new features and functions at least three times a year and be able to choose which features they want to deploy and which they’d prefer to wait on.  Most importantly, what the customer builds will not break, as Salesforce scales and releases new products and features.  This underlying ethos has been one of the reasons Salesforce has been so successful. As a customer, you get a set of shiny new building blocks and whether you go completely off script and build your own unique structure or follow the instructions exactly is entirely up to you – and the promise is that future upgrades will not break your creation no matter what you have built.

One of the very few instances where Salesforce decided to give their users a whole new set of building blocks was the release of Salesforce Lightning.   Salesforce Lightning was an entirely new user interface, built upon an entirely new framework (Lightning Web Components), with separate and new functionality from the traditional Salesforce which was renamed to Salesforce Classic.  Lightning fundamentally changed what was possible with Salesforce, as processes could now be executed client side rather than solely on the server side.  Customers weren’t forced to switch to Lightning, but the newest features would be built exclusively on Lightning as an incentive to move over.  It took a while but a majority of Salesforce orgs have made the transition from Classic to Lightning.  Lightning migration projects became the norm and change management programs kicked into gear to make sure users understood how to work with the new user interface.  There was a period of growing pain as Lightning struggled to have feature parity with Classic, but with time the kinks got ironed out and the benefits outweighed any potential hesitations of moving over.  Now Classic is more of a rare bird, sometimes seen used by more complex, older orgs, but also used by some old-school purists. Though generally speaking, Lightning is the default for new orgs and Classic has finally grown into its name.

Earlier this year, Salesforce again announced a rare item that will fundamentally alter the landscape of existing Salesforce orgs – the retirement of the ability to create new Workflows and Process Builders.  Flow will stand alone as the single point and click automation tool on the Salesforce platform.  This would be like removing a few types of building block shapes altogether and replacing them with new blocks that look different but can be configured in a way that functions like the old blocks. There has been a fair amount of controversy within the Salesforce ecosystem with the announcement of this change.  For one, Workflows and Process Builders were and are relatively easy to build.  “Accidental Admins” have been utilizing them for years to streamline and codify business processes within Salesforce.  The user interface is intuitive and a programming background is not needed to use these tools.  One could even go so far as to say that Workflow Rules and Process Builders have been some of the underlying elements of the Salesforce platform that have made Salesforce so successful. 

That said, when Flow was introduced, it brought with it some redundancies in terms of Salesforce automation capabilities. These redundancies can ultimately lead to fragmentation of automation solutions, confusion within business workflow, and underlying performance and processing issues.  The consolidation to one automation tool ultimately makes sense, and Flow is way more robust than Workflows or Process Builder ever claimed to be.  With Flow, order of execution can be managed, automation can span objects much more easily, arrays can be used – and records can be modified, created, and even deleted across objects.  The notion of before and after save events (like with triggers) come into play to enhance system performance, among other benefits.  And like what happened with Lightning, all the love in terms of the development of new functions and features in the automation realm has gone to Flow over the last few releases.  There is only development happening in one of the declarative point-and-click workflow tools, and spoiler alert, it isn’t with Workflow Rules or Process Builder.

If Flow has more capabilities and overall upside than the other automation tools, the evolution away from the legacy tools should, in theory, be welcome.   However, the transition to Flow has not been without controversy.  The reason it has been a controversial move, similar to Lightning’s initial reception, is that it will require both migrating old logic held in Workflow and Process Builders to Flow, as well as learning the Flow Builder tool itself.  In short, it is not an easy task.  And because Flow is more feature-rich and utilizes object-oriented programming principles significantly more than its predecessors, it can be harder for the “Accidental Admin” to learn how to best use the tool.  An Admin creating Flows needs to have a basic understanding of concepts like variables, loops, arrays, and DML statements. Understanding how to write Flows with a “best practices” approach is more important than ever.  Knowing how to process bulk actions, how to write Flows in a way that is efficient, and understanding tradeoffs that will save processing time are all important notions. While Flow is a more sophisticated tool, it is still generally intuitive and there is no question that it will make the Salesforce platform more robust. At some point, Workflow Rules and Process Builders will seem antiquated and become a distant memory.

But that time is in the future and the need to move to Flow is now.  While a firm date hasn’t been set yet, we will lose the ability to create new Workflows and Process Builders first and it isn’t a far stretch to believe at some point in the future existing Workflows and Process Builders won’t work anymore.  The turning off of the creation of new Workflow and Process Builders is meant to happen sometime “near the end of 2022” which is well, now.  For some companies with the right personnel, moving over to Flow will become an internal project.  For those who need help, Acquis has created a process embedded in a fixed package that can help you migrate your existing setup to Flow, utilizing best practices while focusing on the next-generation Flow architecture. The beauty is that once a Flow framework is set up, it is much easier to update than it is to create one from scratch.  Additionally, while it does force some companies’ hands, it is also a great opportunity to review those old workflows and see if they are still needed – to act like Marie Kondo and re-write only those Workflows which actually bring us joy (or in this case, business value.)

Salesforce has created a Workflow Rule migration tool but unless you have relatively few items to move over, it is a stop-gap at best. There are a few limits to the migration tool, like the inability to reference record types and to migrate rules which use the operators does not contain, includes, within, and excludes. Acquis advises to come up with a comprehensive plan prior to making the transition to Flow, in terms of the strategy as well as the execution of that strategy.  As with any architectural decision, it makes sense to understand the pros and cons of different approaches, what tools to utilize and to move forward with the approach that makes the most sense for your organization. 

It behooves all Salesforce Admins to start digging into Flow.  It may be intimidating but the earlier it is embraced, the easier it will become to learn and utilize.  Acquis can help you get started on your journey so that your organization is ready by the time Workflows and Process Builders are turned off.  Salesforce doesn’t often throw us curveballs when it comes to the fundamental building blocks of the platform.  In the rare cases when these events do arise, you can be certain that there has been a ton of thought and time behind the reasons for the change.  As customers when presented with these fundamental shifts, it makes sense to embrace the change.  With Flow, the earlier the future is embraced, the easier it will be to make the transition and ultimately get the best out of the Salesforce platform.