The world of Salesforce automation is becoming more crowded and complex then ever before! Spring ’15 added some new tools to the arsenal. When do you use which? What are the benefits over one or the other? How much wood could a woodchuck chuck if a wood chuck could chuck wood?
These are the questions plaguing Salesforce Administrators around the world. So pull up a chair or your standing desk and let’s talk about automation.
There are three category of options: The Admin Friendly (declarative), The Intermediate (declarative), and the OMG I need a Developer (Code).
The Admin Friendly (declarative) includes Workflow Rules. Our friendly and familiar standard with field updates, email alerts, task creation and outbound messages.
The Intermediate (declarative) includes the new Lightning Process Builder and Visual Workflow. These are new to most administrators out there and can be confusing, especially Visual Workflow. To get the most out of Visual Workflow it helps to know some programming jargon, but the tool is still completely button-click friendly. You can check out my Wizard’s Apprentice YouTube channel if you want some Visual Workflow tutorials.
OMG I need a Developer includes APEX the code of salesforce.com. It can also include Visualforce pages – although you can do many basic and nifty things without knowing APEX. For most automation purposes, you do need to know code.
So which to use? My personal mantra is to use the simplest and easiest method to get the job done. So if I only have to do 1 field update or email on an object – I’ll use Workflow Rules. For more detailed actions or workflow processes I’ll use the Process Builder. When I’m handling lots of records or very complicated logic, I’ll use APEX.
For each project, you should consider the pros and cons for each tool.
The Pros & Cons
is really good at handling complicated logic and lots and lots of records. When you’re dealing thousands, hundred of thousands, millions of records – your looking at using APEX. You can use APEX for more simple use cases, but then that takes the flexibility away from the Admin. Most administrators do not know how to code in APEX. The major “con” for APEX is the requirement of needing an APEX developer. This also means there’s a time component. If you need a “quick change,” you’re depending on the developer’s schedule. The developer needs to update the code and test class. Then you’ll need to functionally test it and deploy. APEX is great for complicated and large processes, but there are often easier and more accessible methods for the smaller stuff.
are fast, easy, and button-click friendly. The Workflow rule will “trigger” based on a set of criteria at which point the actions will either be immediate or based on a time-based schedule. Workflow rules can do a lot. They can update fields for the object it’s being “triggered” on and in certain circumstances update records for their parent record. Workflow rules can send out emails and create tasks. There’s also the rarely used Outbound message for integration.
One downside to the Workflow Rule is organization. Each set of criteria requires a new workflow rule. This means you’ll have many workflow rules for the same workflow process. For example, you want to have similar but different actions fire based on the stage of the Opportunity. This will require 1 Workflow rule per stage. The only way to organize this is by the naming convention of the rule – which can get messy.
A second downside to workflow rules are from the management perspective. You have no way of knowing what the actions are without “drilling” into each Workflow rule. That can be quickly annoying.
The final downside is the limitation. You are limited in what records you create and update, and you don’t have access to many of new features (chatter) available.
is more complicated for most users to learn and use regularly. Unlike Workflow Rules, you have access to many other actions. You can create nearly any record and can update nearly any record. The two downsides to Visual Workflow are the difficulty it to learn the tool and it cannot be “fired” on it’s own.
Lightning Process Builder
is the new version of Workflow Rules. You can do a lot more different types of actions – including having a Flow from Visual Workflow get called. This gives you a lot of different powers. It’s built on top of Visual Workflow so you have almost all the same power of that tool. A Process can have multiple criteria diamonds – basically the equivalent of nesting multiple Workflow Rules together on one page. You can also see all the actions for each set of criteria that will be called.
One downside of the Process Builder is you currently only have access to the records and fields the running user has. Workflow rules would let you update an “invisible” field to the user. This was great for lots of data validation and controls. With Process Builder (and Visual Workflow) the field must be visible and editable by the user in order for the tool to update the field.
There are some other downsides with the current version. The tool isn’t truly “bulkified” so managing many many records will be problematic. There are also some limits on the number of “criteria diamonds” you can have and the number of active processes per object.
Another limitation\irritation of Process Builder is versioning. You can’t simple go in an update a Process. You need to clone it and then activate the clone. Just seems very old school!
I’m a little bias since I was on the Process Builder pilot when there was no versioning. You had to create a new process completely and it made for a very messy screen.
Since Process Builder is really building a flow behind the scenes and an activated flow MUST either be created as a new version or a completely new Flow. So it’s really a Flow limitation that gets inherited by Process Builder. With Flow, I actually like the versioning since I can create updates and not have them activated until I’m ready. Plus, when I do activate, I don’t have to go update all the places that reference that Flow since the primary URl and API name hasn’t changed.
For me, needing to use multiple Workflow Rules to manage different criteria for the same process, makes a big difference when choosing between WFRs & the PB. I just discovered that using the Process Builder, with multiple action blocks for different criteria, only counts as one ‘active workflow rule’.
Something to bear in mind if you have a large org and you’re in danger of exceeding object’s limits.