Apparently, this is the second article in a series questioning best practices on Salesforce features and functionality. Yes, I said series because there are more questions and theories coming.

Salesforce has been improving their click-based automation game in the past five-ish years. Two years ago, Salesforce gave Flow a major overhaul by re-branding the tool to Lightning Flow Builder, giving the UI a face lift, and simplifying the components within the tool to become the HATIC (that’s “Head Automation Tool In Charge” for those of you that aren’t down with the lingo). A few years before that Process Builder was introduced as the new automation tool that will help admins further customize their org without writing code. It was meant to replace Workflow Rules, the OG automation tool.

With the introduction of new or improved tools, people have been trying to determine the best way to evolve their automation strategy on the platform. Workflow rules were simple and limited so the only strategy needed was to not have them contradict each other. Process Builder introduced a need to approach design and strategy similar to building triggers. Flow has always been the most complex declarative tool and forces more conversation around strategic design.

The automation strategy within an org has become more important than ever. Flow is getting new features and enhancements with every release and it is forcing admins to stay on their toes.

Let’s look at a few automation strategies with Process Builder and review the validity of each.

Process Builder to Replace Workflow Rules

This was one of the first strategies to be deployed when Process Builder was introduced. It seemed that Salesforce was going to deprecate Workflow Rules entirely with the addition of the new tool, but they are still alive and kicking. I hope Workflow Rules never go away because I believe they still have a purpose. Workflow Rules are reliable for simple use cases and are a handy tool to leverage when tricky configuration is needed.

Building One Process Builder per Object

This strategy is situational and should be used if there isn’t a lot of automation on an object, either within the Process Builder alone or using multiple tools. I’ve seen strict adherence to this strategy that resulted in a maintenance nightmare. In theory, it makes sense to have a single functional component control all automation to ease the administrative burden.

In reality, each action within a Process Builder needs to be evaluated separately to understand the business relationships between the actions. For example, if the Process Builder is a series of IF statements based on a few pieces of criteria then it makes sense for it to all be contained within the same Process Builder. If each action serves an unrelated business purpose, further analysis should be given to where each action lives.

Extending Process Builder with Flow

Flow has always been used for the most complex declarative automation needs and is the last resort before a coded solution. When Process Builder was introduced (or maybe slightly after), Flow also received a major enhancement by gaining the ability to be invoked by a Process Builder. Prior to that, Flow needed to use an input screen to initiate (this is about the time I really got into Flow and learned how powerful it was so I may be wrong about it’s usage before Process Builder/invokable flows). This allowed Flow to be launched based on record changes on one object and have a farther reaching downstream effect on other objects, whether they were directly related or not.

Revising the Strategy of Using Process Builder and Flow

The past two releases and the upcoming Winter ’21 release have started to redefine how both Process Builder and Flow should be used. Until now, Flow had to either be initiated by a screen input within the Flow or via Process Builder. The last release introduce record change based launching of Flows and the next release takes those features even further.

Before-save and after-save initiation has been a huge addition to Flow and have allowed admins to move away from Process Builder in some instances. These types of flows behave more like the reliable Workflow Rules and increase processing efficiency within the platform, but there are still limitations within the available components that might force your hand back to using a Process Builder. One of which is that you can only update the record that initiated the Flow. Another is that you cannot invoke another Flow.

There are even more Flow enhancements in the next release that help push these boundaries:

• Entry Criteria in Record-Triggered Flows
• Access Related Records in Autolaunched Flows
• Before-Delete Flows

The automation landscape is changing with every new release. If your org is growing and new requirements need automation, you must stay on top of the new features and changes. These recent updates have the potential to be game changing once they are fully fleshed out. Don’t fall behind!

How to Redefine Your Automation Strategy?

I recommend a methodical approach when evaluating how to redefine your automation strategy. If the trend continues, more features will be added to Flow to increase its capabilities and slowly phase out Process Builder. This phasing out will still likely take a few years so it would be silly to jump in your org tomorrow and start re-engineering automations.

I recommend getting your hands on Flow with the new features so you can experience the capabilities and limitations firsthand. The best way to see how far you can stretch functionality is by working with the tool.

I recommend reviewing your automation configuration and logically grouping each function by business purpose. It will be a valuable exercise to rebuild portions of the automations in a sandbox and testing as an end user to understand the impact of your changes.

Lastly, I recommend not trying to get it right the first time and avoid over-analyzing your strategy. You grow by failing. You learn by failing. You move forward by failing. My definition of FAIL is your First Attempt In Learning. Don’t be afraid to take the first step.