Salesforce Process Builder Best Practices
By: Alex Peattie
Tags: Salesforce, CRM, Process Builder, Lightning Process Builder, Salesforce Tools

Common actions that occur in the processor process are submitting the record for review, alerting relevant people, and updating associated records or fields.

Typically you only want any actions to occur once when the record enters the new stage, for this to occur you want to select the ‘execute the actions only when specified changes are made to the record!’ option in the criteria node.

Fig12: Execute only at the time the changes are made

As processors map to key business processes, organisations are often interested in identifying opportunities for process improvement. As a result it is a good idea to plan for detailed reporting requirements on these processes. Organisations often want to report on:

the average time spent in stage X

the count of current records in stage X

the overall process completion time

all records that have been in stage X for longer than …

By reporting on this type of information organisations can identify bottlenecks and inefficiencies in their business processes, understand the behaviour of the system, or spot exceptions that need immediate attention. To enable this type of reporting we need to capture the history of transitions over time, not just the current state.

Fig13: A Salesforce Report

There are a couple of ways we can do this, the simplest is to add a timestamp field for each stage in the process, we can then update the timestamp when we complete that stage. This method has limitations if we allow the process to move forward and backward as the timestamps will be overridden and our reporting won’t match what actually occurred.

The best method is to enable Field History Tracking on the object, then select the field that is used to track the state of the process. Now modifying the state will add an entry to the History related list. All entries in the History related list will include the date, time, nature of the change, and who made the change. This allows for the level of reporting most organisations are looking for. Note the field history data is only retained for up to 18 months within Salesforce.

Fig14: Enabling Field History on an Object

So what if an object needs more than one processor?

It is common for business requirements to necessitate multiple processors for an object. An example here might be Cases, we often see a processor to track the Cases current status #case_process_status and a processor to track the Cases current priority #case_process_priority. The execution of one may even indirectly invoke the other.

Another scenario is when an object has Record Types that dictate two different processes. Be more careful in this scenario, your goal should be to minimise the number of processors per object without losing readability. So, if there is a lot of overlap between the two processes (they have common states) then consider condensing the design into a single master processor, but if they are largely independent, then separate them.

We advocate the use of multiple processors per object where necessary, however a good architect should always be looking for ways to minimise their propagation.

Finally, like initiators, processors should be designed with mutually exclusive action groups. Avoid using the ‘Evaluate next criteria’ option wherever possible, as a record may only be in one state at any time it should not be relevant.

Actions — how to remove the risk of human error

Action processes are our catch all. All ad-hoc or independent automations should be modelled in the actions process.

Fig15: Evaluate the next criteria

Ideally we have one action process per object. Within the process each action group will be independent and here you should use the ‘Evaluate next criteria’ option as default. Think of the action process less like a process and more like a list of rules. We just bundle all the rules into a single ‘bucket’ we call the action process.

Generally the action process will execute tasks that occur once some manual action has occurred. Like when a record owner changes — alert the new owners manager and the old owner, or when one object is linked to another — update a counter on the parent, or if a value exceeds a limit — post a notification to chatter.

More advanced use cases can start using the confidence scores from Einstein to automate actions. Using Einstein in your processes makes your processes smart — meaning you are no longer hardcoding the rules into the process.

Fig16: Einstein confidence score

For example it’s possible to build a process that leverages Einstein Lead Scoring to route and prioritise your leads. Einstein Lead Scoring uses artificial intelligence to score your leads by how well they fit your company’s successful conversion patterns; so you don’t need to know which characteristics indicate a high priority lead, you don’t need to build a matching algorithm into your process, and you don’t need to modify the characteristics as they change — because Einstein will automatically and accurately do this for you based on the history of all previous leads!

This can all be achieved in a single action group within the object actions process.

Action processes become more complex when you add scheduled actions. To add scheduled actions you’ll need to have checked the ‘execute the actions only when specified changes are made to the record?’ option on the criteria node.

As action groups are assessed in order you can place all action groups that include scheduled actions at the bottom of the process. Note again that these are mutually exclusive, so ensure your criteria logic is sound.

Subprocesses — how to simplify the complexity

Subprocesses are simply processes that are invoked by other processes. When creating a new process choose ‘It’s invoked by another process’ from The process starts when drop down list.

There are many uses for subprocesses, they are far more than just a convenience. Typically employed for reusability, by bundling business logic into a subprocess, you can then call them anytime you need. This avoids rewriting the same logic in many places.

In her blog Jenwlee gives a nice overview of DRY (Don’t Repeat Yourself) principles using Process Builder subprocesses. The goal here is to increase maintainability and convenience by abstaining from duplicating logic actions in multiple action groups.

Fig17: An action to invoke a subprocess

A common example is a subprocess that first checks a customers preferred contact method before sending notifications. This can then be executed from any object that has a relationship with Contacts. In this way the primary process decides when to notify the contact but outsources the logic of how to contact the customer (i.e. via email, sms, communities chatter message) to the subprocess.

Subprocesses also enable nested IF statements. So, a processor may invoke a subprocess when the state of an object changes, the subprocess can then further break down which actions to take. For instance we may only notify a manager if we are in state X and the value is above Y. Using subprocesses in this instance allows us to keep the criteria in our processor pure by maintaining its granularity at the ‘check for current state’ level, and then provide finer granularity logic (value is above Y) in the subprocess.

Note you can’t call scheduled actions in a subprocess so it cannot be used as a workaround to make action groups with scheduled actions compatible (non mutually exclusive).

Finally it is worth highlighting that you can call the same subprocess multiple times within the same action group. This feature can be very handy when you need to execute repetitive actions with slight changes. Think sending notifications to multiple people or updating multiple related records. Because immediate actions are executed in order (top to bottom), you can prepare the data then call the subprocess repetitively.

Fig18: Calling the same subprocess twice

A more productive way of doing this may be to call a Salesforce Flow subprocess, rather than a Process Builder subprocess. The final best practice for subprocesses would be to ensure you use the right tool for the job, so we encourage you to get an understanding of Flow too as it is way more efficient at achieving some tasks that seem clunky in Process Builder.

Summary — go forth and automate

Salesforce Process Builder is a very powerful tool for automating business actions. Thinking of Process Builder as a state machine execution engine is a more accurate way of understanding how it models business processes, despite it’s name (a common problem for ‘Salesforce’).

Following the simple patterns outlined by the four process models above will ensure you are on the right path to developing maintainable and therefore more agile processes. As with any framework there may be situational exceptions that arise, but an understanding of these practical concepts will aid your thinking and solution design.

Have fun process building!