Salesforce Administrator, you are armed with all of the power in the org at your fingertips! And so many automation options – workflow rules, process builders, flow, oh my!
Then the errors start. Some automation is conflicting with something else and now your users can’t do what they need to. All the complaints come to you.
How did this happen?
Maybe you inherited an org and you hit the ground running with new features. Maybe you built the org from the ground up and have forgotten that you are not infallible. The problem here is that now you’ve got several types of automation firing at different times during the order of operations and – without careful planning – they may be overwriting each other.
If this is the case for your org, consolidating your workflow rules and process builders is recommended. Why?
Auditing your automation lets you evaluate what is in use and what isn’t. As admins, we are often too busy to look at what’s been built previously to determine if it’s in use anymore. It can be hard to prioritize clean up when there’s building to do.
Consolidating makes your automation more efficient. Salesforce has limits, and we never want to get to a point where we’re hitting one. The more automation being fired in a transaction increases the likelihood we will.
Why Process Builder is the Best Tool for Automation
Workflow rules are handy for one-off automation, but allow me to persuade you to use Process Builder for the majority of your automation.
Process Builder lets you set the order automation fires in. You can’t tell Salesforce in which order your workflow rules should fire. This can cause issues because some things need to fire before others. With process builder, you can order nodes in the way you’d like them to fire.
Invocable process builders let you set controlling criteria. I’ve seen many orgs where a status field controls a bunch of workflow rules. With an invocable process builder, that status can fire its own process builder and you don’t have to worry about adding it to the criteria. Once the record hits that status, it enters this new process builder and goes from there.
Control everything in one place. You need to autolaunch a flow, so you build a process builder. With your workflows still in place, you now have to manage your automation in multiple locations. By consolidating your workflow rules into your process builder, everything is in the same place. Of course, when you make an update or addition, you have to consider how it will affect the whole process.
If you read the blog from my colleague Carl about consolidating triggers, know that the same principles apply here. One process builder per object should fire on record change. Otherwise, we’re where we were with all the workflow rules: which is going to fire first?