We recently kicked off our new series on choosing the right Salesforce automation. Today, we’re taking a deeper dive into the first two options for real-time automation in Salesforce: workflow rules and process builder.
Using Workflow Rules
Workflow rules should be the first type of real-time automation you consider—with one major caveat. Salesforce has indicated that they will not be adding any new functionality or upgrades to workflow rules. Given this, we generally recommend avoiding workflow rules in favor of process builder unless you already have workflow rules on your object, do not already have process builders on your object, and meet the following use cases for workflow rules:
When working with edition limitations (for example, Professional Edition only allows maximum 5 processes; 1 per object)
For simple field updates on the same object (but without dynamic picklist values or IDs being set)
Email alerts
Task logging
- Outbound messages (via an integration and only when necessary)
If you don’t meet these conditions for using workflow rules, move on to consider process builder.
When Should I Use Process Builder in Salesforce?
- When using a field reference for a picklist field update or when setting a lookup field. These are the primary limitations of a workflow rule.
- When you need to reference information from parent records. Use this in your update function.
- When you need to create additional records. For example, custom history tracking.
- To mass update child records. For example, changing the opportunity owner when the account owner changes. (Keep in mind the limitations below.)
- To launch a flow. The only alternative way to launch a flow is through Apex or a button that a user must click on.
- To declaratively instate a platform event. Which you can write Apex to subscribe to—ultimately replacing the need for an Apex trigger.
- To declaratively call an Apex class. Also removing the need for an Apex trigger—for example, when invoking a third-party tool like DLRS.
Need a Salesforce
Expert?
What Do I Need to Know When Using Process Builder?
If you select process builder for one of the use cases above, you’ll need to watch out for a few things. With features like process builder, Salesforce puts powerful, no code dev tools in the hands of admins. If used improperly, these tools can cause dramatic damage to your Salesforce instance. So if you’re an admin, think like a developer and heed the warnings below.
You should only have one process builder per Salesforce object.
This means that you might have many actions built into a single process builder—and that’s the right approach. (One exception to this rule is when you have one process builder for creation events and one for update events.)
Be very careful about the order of actions in your process builder.
Because you will probably have multiple actions in a single process builder, you need to pay attention to the order in which things happen. If you don’t, one of two issues can result: some automations may never be hit, or multiple automations may be hit in succession.
As an example of the latter, let’s say your process builder is set to assign the lead when the status is MQL and assign the lead when the next call date equals today. If your marketing automation system sets both values simultaneously, a record may be assigned twice because it will hit both steps of the process builder.
To avoid this, make sure that you sequence your automation so it will hit the steps exactly as expected.
Make sure you handle empty values.
Be mindful of when a filter value or update value may be empty and build the possibility of an empty value into your logic. Often, this simply means adding an extra filter to your process builder to accommodate for an empty value.
For example, if you’re running an automation on a contact and you only want it to fire when the contact status equals qualified and the contact’s account status equals prospect, your automation will catastrophically fail if the account value is empty. To prevent this, you would add “contact’s account is not null” to your logic.
Understand maximum data volumes.
Because process builders can be CPU intensive and sensitive to high data volume, errors like 101 SOQL errors or CPU timeout can occur. This can happen if your process builder is invoked during large data processing events like data loads. This also applies to when process builder mass updates child records. For example, if you attempt to chage contact owner based on account owner you’ll run into issues if you have 500 contacts at an account.
Avoid the 2 most common admin errors.
The two biggest mistakes people make are enabling recursion when they don’t understand what it means and failing to ensure that the process builder is running only on desired change events and not all updates. Recursion fires the process builder multiple times can cause CPU errors — more stuff’s happening.
What issues have you run into with workflows and process builder? We’d love to hear from you!
Next up in the series, we’ll be discussing flows. Follow us on Twitter or LinkedIn for the latest.
