How Salesforce Flow Will Impact Organizations

Throughout its history, Salesforce has rarely made decisions that will fundamentally alter the landscape of existing Salesforce configurations. This predictability has been part of its basic ethos. Salesforce will provide access to its flexible and secure state-of-the-art platform while the rest is up to the customer. The customer can access to new features and functions at least three times per year. The customer can then 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. Customers get new building blocks and can choose to build a unique structure or follow the instructions exactly. They also receive a promise that future upgrades will not break their Salesforce instance regardless of how customized it is.

Salesforce Lighting provided users a whole new set of building blocks. It was an entirely new user interface, built upon an entirely new framework — Lightning Web Components. It provides a separate and new functionality from the traditional Salesforce — renamed Salesforce Classic. Salesforce Lightning fundamentally changed what was possible with Salesforce. Users could execute processes on the client side rather than solely on the server side. While customers could opt out of Salesforce Lightning, the newest features would be built exclusively on Lightning. This was done as an incentive to move over. 

Salesforce Lighting Becomes the Primary Salesforce

It took a while, but most companies transitioned from Classic to Lightning. Lightning migration projects became the norm, and change management programs ensured users could work within the new user interface. Salesforce Lightning originally struggled to have feature parity with Classic. With time, however, benefits outweighed any potential hesitations of moving over. 

Classic is sometimes used by more complex, older organizations, and some old-school purists. Generally speaking, Lightning is the default for new organizations, and Classic has grown into its name.

A New Fundamental Shift: Salesforce Flow

Earlier this year, Salesforce again announced an item that will fundamentally alter the landscape of existing Salesforce organizations. Salesforce retired 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 is akin to 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 some 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 one does not need a programming background to use these tools. One could argue that Workflow Rules and Process Builders have been some of the underlying elements of the Salesforce platform that have made Salesforce so successful. 

Streamlining Automation

When Flow premiered, it brought some redundancies in terms of Salesforce automation capabilities. These redundancies can ultimately lead to fragmentation of automation solutions, confusion within business workflows, and underlying performance and processing issues. The consolidation to one automation tool ultimately makes sense. Flow is way more robust than Workflows or Process Builder ever claimed to be. Users can manage order of execution, create arrays, automation can more easily span objects, and records can be modified, created, and even deleted across objects. Bbefore and after save events (like with triggers) comes into play to enhance system performance, among other benefits. Development of new functions and features in the automation realm has gone solely to Flow over the last few releases.

Shifting to Salesforce Flow

Since Flow has more capabilities and overall upside, shifting away from the legacy tools should be theoretically welcome. However, the transition to Flow has not been without controversy. It requires migrating old logic held in Workflow and Process Builders to Flow and learning the Flow Builder tool itself. In short, it is not an easy task. Flow is more feature-rich and utilizes object-oriented programming principles significantly more than its predecessors. This potentially makes it 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, efficiently write Flows, and understanding tradeoffs that will save processing time are all important. While Flow is more sophisticated, it is still intuitive. 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.

How Acquis Will Help the Salesforce Flow Transition

But that time is in the future, and the need to move to Flow is now. While no firm date has been set, people will lose the ability to create new Workflows and Process Builders. Believing that existing Workflows and Process Builders will no longer work in due course is not unreasonable. Decommissioning creating new Workflow and Process Builders should happen “near the end of 2022.” For some companies with the right personnel, moving to Flow will become an internal project. Acquis has created a process embedded in a fixed package that can help migrate your existing setup to Flow. This package utilizes best practices while focusing on the next-generation Flow architecture. Managing and updating Flows is much easier than creating one from scratch. It also provides an opportunity to review old workflows and determine if they still have utility.

While Salesforce has created a Workflow Rule migration tool, it is a stop-gap at best unless there are few items to migrate. There are limits to the migration tool, like the inability to reference record types and to migrate rules that use “does not contain,” “includes,” “within,” and “excludes.” It behooves all Salesforce Admins to start digging into Salesforce Flow.

Acquis advises developing a comprehensive plan before transitioning to Flow. The plan should include the strategy and the execution of that strategy. With any architectural decision, it makes sense to understand the pros and cons of different approaches, what tools to utilize, and how to move forward with the approach that makes the most sense for individual business contexts.

Curious about how to get the most from your Flow instance?