Salesforce Automation Guide to Workflow Rules, Process Builder, Flows, and Apex
Having spent a considerable amount of time with companies helping tailor their Salesforce systems, admins and developers have seen their fair share of interesting automation.
Some companies have really taken to Salesforce’s various automation tools, and some are relatively new to Salesforce’s automation capabilities. In this article we’re going to take a look at four different automation tools; workflow rules, Process Builder, Flow Builder, and Apex code, to develop a better understanding of each’s benefits, limitations, and use cases.
_____
Workflow Rules
We’ll begin our discussion at the most basic form of Salesforce automation, the workflow rule. One of the last bastions of Salesforce classic, workflow rules are the simplest method of automating internal processes and procedures.
A workflow rule can be boiled down to a series of if/then instructions that allow an admin to automate repetitive tasks (for example, if it’s cold outside, then bring a jacket). If/then statements, while basic, do allow for a hefty amount of automation, especially within database systems such as Salesforce. The table below breaks down the capabilities of these workflow rules.
The triggers and actions for workflow rules can be used in any combination, and even be set to include a time delay. This time delay feature is a great tool if you’re looking to, for example, create a task for a record that goes un-edited for a certain amount of time, or change the status of a case that remains open for too long. The possibilities for workflow rules, while limited, are at the same time almost endless. Flexing and pushing your ability to utilize these rules will not only help build your skills as a developer but also create a solid foundation for other Salesforce automation tools to be built on.
It is important to note that workflow rules, while still offered and supported by Salesforce, are not going to be receiving any future enhancements. Salesforce is not directly saying it, but admins and developers read “no future enhancements” as basically saying that Salesforce is likely to retire workflow rules at some point in the future. Don’t panic though! If you’re working with an older organization which contains a decent amount of workflow rules, then we suggest taking some time to re-create these rules with other automation methods in a sandbox, just to be on the safe side. Salesforce has also stated that any new functionality that they wish to add to workflows will be delivered through our next topic, Process Builder.
_____
Process Builder
If workflow rules are like a fitness enthusiast who enjoys running and occasionally weightlifting, then Process Builder can be thought of as workflow rule’s steroid-injecting, lifting the entire machine, what’s a cheat day brother.
Ok, I know that metaphor is a little out there, but the concept still tracks. Process Builder is Salesforce’s replacement for workflow rules, built specifically on the lightning platform. Not only can Process Builder automate the same functions as workflow rules, but it expands those functions to include actions like:
– Creating records (not limited to only tasks)
– Updating related records
– Launching quick actions
– Creating chatter posts
– Launching flows
– Calling Apex code
– Submitting records for approval
– Calling other processes
Process builder is still structured as if/then statements, following the same automation method as it’s predecessor. Unlike workflow rules though, process builder gives admins control over the sequence that if/then statements get evaluated in. With workflow rules, a set sequence can’t be established, and with the inability to call rules from other rules, admins had to create some clever workarounds to achieve specific functionality. With Process Builder, the days of those workarounds are long gone.
Another area of expansion with Process Builder is the amount of related objects that can be touched by automation. With workflow rules, admins were restricted to only making edits on related objects that were parent records in a Master-Detail relationship. Process Builder expands this to allow any related object to be altered in a single process.
When working with older systems, please be advised that Salesforce suggests using either Process Builder or workflow rules. This is because workflow rules can’t be sequenced for operation, meaning it’s hard to reliably predict what rules will fire at what time during a record change. If you are currently using a split system with some automation in workflow rules and some in Process Builder, then it is a good idea to take the time and switch everything over to one system.
_____
Flows
If you’ve been an admin or developer for any considerable amount of time, then you’ve most likely heard the word “flow” tossed around quite a bit. In this article alone we’ve already discussed workflow rules, so how’re they different from the flows we’re talking about here?
Admins and developers often use the term “flow” to stand specifically for automations created using the Flow Builder tool, a graphical programming tool that expands upon the functionality of Process Builder in several ways. Flow Builder, unlike Process Builder, allows for the creation of very complex automation sequences, normally involving multiple logic branches and many different actions. Unlike Process Builder, however, a flow (a specific series of actions created using Flow Builder) must be called into action and cannot be directly triggered by a field change.
That last paragraph got a bit technical, so let’s break down what we mean with an example. Let’s say you are trying to build an automation that creates a new record, but in order to create that record you’ll need to gather some information from the user. With Process Builder this task would be almost impossible, but with flows the process is easy!
Flows can be broken down into two different types, auto launched and screen flows. Auto launched flows behave very similarly to Process Builder; they don’t require user input and are mostly used to expand Process Builder’s logic capabilities. Process Builder handles both series of if/then statements and concurrent if/then statements very well, but starts to become very impractical when dealing with a combination of the two. To help keep everything sorted, auto launched flows change if/then statements to graphical images, showing a more digestible understanding of how a process goes through its various stages and conditions to completion.
In the example we proposed where we need to gather information from the user, the latter type, screen flows, would be used to achieve this functionality. Screen flows inject screen elements into automation, prompting the user to enter important information before completion. This feature is not available with Process Builder, and therefore is one of the unique tools that differentiate Flow Builder.
It is very important to note that both styles of flows within Flow Builder, auto launched and screen flows, don’t get called to action in the same way that Process Builder processes and workflows do. Where those two can be called by simply changing a field, flows must be called from either a user or another process.
Often, admins and developers have to use a combination of Process Builder and Flow Builder to achieve a desired automation. Salesforce offers a great article on various methods and tactics to use these tools jointly. That article can be found here, and is a great read for anyone looking to up their automation game.
_____
Apex
If your automation can’t be done with workflow rules, Process Builder, or Flow Builder, then finally we get to our last automation tool, Apex. Apex is the code language that Salesforce is built on, meaning writing automation with this tool can alter the foundation of your Salesforce organization. Developing with apex code is not something you should fear, but also not something you should take lightly.
Your best bet is to first make sure that what you are trying to accomplish can’t be done with any combination of the tools we previously discussed. If that truly is the case, then the automation can be accomplished by writing apex. It’s important to remember that the only limit to your ability to automate is your knowledge of coding. Experienced coders who know more of the language can develop some awesome customizations, but apex writing is a long, drawn-out process involving several layers of testing code and an even longer implementation cycle.
To fully discuss apex code would take many articles, so let’s just highlight some of the features specific to apex coding:
– Delete records
– Update unrelated records
– Create email templates that reference multiple records and objects
– Literally anything else you can think to program
_____
Knowing all the automation tools available at your disposal is critical when tailoring a salesforce organization to fit business processes. When utilized correctly, each one of these automation tools can streamline sales funnels, and get your teams selling quicker and easier. So get automating!