Ever since the Summer ’16 release notes dropped, the Salesforce Community has been going ecstatic over the one and only Process Builder improvement. The Community is so excited with this one feature, that I have not seen anyone complain about Process Builder only had one improvement. The reason is this improvement is a game changer in the Process Builder world, and it will change the way that we build our Process Builders.
Note: Evaluate the Next Criteria has one limitation currently. It doesn’t work with Scheduled Actions (which makes sense). So, if your Process Builder has a Criteria that includes Scheduled Actions, you’re out of luck for continuing any further down the Process Builder (and that particular Process won’t really apply to this Blog Post). So keep in mind during this post that any Process Builder with a Schedule Action can’t be included.
One Process Builder to Rule them All!
You’re probably asking yourself why would we want to build an extremely long Process Builder? This idea comes from attempting to mirror the Apex Trigger best practice and design pattern. Yes, there are additional benefits to this design pattern with Apex as opposed to Process Builder, but the main points still ring true.
#1 – Keep it Simple
No longer do you need to search through tons of Process Builders trying to understand what all is going on behind the scenes. You’ve got all of your logic in one spot for you to look at (excluding Scheduled Actions). Heck, Salesforce even mentioned how it makes it easier in the release notes!
#2 – Control Your Order of Execution
So, just like with your Order of Operations, it is important to be able to know what order you execute Process Builder actions. However, unlike the Order of Operations where we can follow a consistent process every time… with Process Builder we don’t know which order our Process Builders will execute in. If we have 15 different Process Builders on the Cases Object, then we have no control over what order they will be executed. It is quite scary when you realize you’ve got zero control over the order your Process Builders run in!
With executing multiple criteria in a single Process Builder we are now able to consolidate all of our Process Builders into just ONE. And, in our one Process Builder we can drag and drop our actions around into the desired Order of Execution.
For a quick summary, creating one Process Builder to rule them all will allow you to simplify your Process Builders for each Object, and will allow you to have consistency in the way your actions are fired. Do you have to do this? No, there is nothing stopping you from continuing to build Process Builders in the same fashion that we previously did. But, I would ask you to consider thinking about incorporating this design pattern into your Orgs once it becomes available.
Salesforce Sidekick 
Question.
One advantage of having multiple processes per object is the ease of deactivation/activation on a per process basis.
Do you have any suggestions/best practice for constructing the per object process to allow for simplistic deactivation/reactivation of the individual processes.
I’ve considered adding a formula field to every object “Active Process” that is true and have that field in every criteria group as either true or false.
LikeLike
You’ve brought up a great point about how easy it is to manage in separate processes. I think the method you mentioned with the formula field is a great solution to that issue. You could also do something like ID is null equals FALSE, but I think that your idea works better than that as it is much clearer what the purpose is in the criteria.
However, that means you’ve got to navigate through your Criteria to actually manage the individual processes and that doesn’t really sound fun. My recommendation would be to use Custom Settings. You could have your formula field (still called Active Process), and check to see if the Custom Setting field for that process is also TRUE/Active. That would allow you to control multiple criteria that relates to one ‘process’ now in your Custom Settings and not have to Clone the PB every time you need to deactivate one.
LikeLike