Our team of admins deploys hundreds of Salesforce automations every year. Given this, we’ve experienced a huge breadth of automation use cases, with a range of outcomes along the way. Recently we decided to pool this knowledge to create a comprehensive guide to Salesforce automation best practices.
Over the next few months, we’ll be sharing our insights in a series of posts that will explore when to choose each type of Salesforce automation, along with major considerations and things we’ve learned the hard way. The considerations that follow will be fairly technical and specific but, taken in a larger context, will comprise a helpful guide to Salesforce automation for admins.
Choosing Your Real-Time or Code-Based Automation
Let’s kick off by looking at how to choose the right real-time and code-based automation in Salesforce. When choosing your automation, there is a logical hierarchy of options to consider. Below, we’ll explore these options in the order in which you should consider using them.
1. Workflow Rules
The first type of automation to consider is workflow rules. Workflow rules are viable for the following use cases:
- 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 non of the above use cases apply, look at process builder next.
2. Process Builder
Choose process builder for the following use cases:
- 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.
3. Flow
- When you need to do a query
- When you need to create records and reference the results in a subsequent update
- To do a screen flow — screen for user to interact with
- To launch an action from a button
- When you need to create multiple or dependent objects/records (for example, when you need to create a record from the account, like clicking a button to create an opportunity and/or product)
- To delete records
4. Apex Trigger
- When working with high data volume. Triggers can perform faster in such situations: if you’re getting process builder errors due to volume, consider using a trigger.
- To control order of execution. If you have something in code and something in process builder and you need them to run in a specific order, use a trigger.
- When everything else is in code already. When you’re forced to build out a complex coded process, it’s a best practice to consolidate your automations in code. Don’t create a rogue process builder here, because your developer won’t know what it’s doing.
- If you need to fire before insert or on delete. (Note: this will change in a future release, which will have flows firing before inserts.)
- When you have really complicated criteria, because apex triggers can execute this much faster. It is possible to cripple your system with a CPU timeout error if you have a process builder dealing with too many operators (for example, we’ve seen this happen with too many “title contains” operators).
Learn more about Apex triggers.
