Salesforce Process Builder has by far been one of the most useful and popular tools for all Salesforce Users. Process Builder is used for automating the business processes in Salesforce. This is one tool that has evolved in the last few years from just a simple declaration tool to an advanced tool with automation capabilities like email send activities, approval processes, post chatter messages, invoke sub-processes and others.

Salesforce Process Builder is now capable enough to accommodate multiple processes with all types of complexities. Here we list down the best practices to follow while working with Salesforce Process Builder.

1. Create reusable actions/processes:

In order to save time and effort, it is recommended to create common actions/processes/activities like email send action, update record action, etc. in such a manner that it can be reused in multiple processes. This can be done either by using the available Quick Actions or by creating these actions in an invocable process. An invocable process is one that can be started only when initiated by another process. Actions configured in an invocable process can be reused by calling this sub-process whenever certain conditions are satisfied in the main process.

2. Avoid overlapping automation on one object:

As there are multiple automation tools available like workflow, process builder and others while creating a new process you must ensure that there is no other automation running on this object. If there is any automation already running, you may need to consider accommodating those conditions in the new process and switching off the older automation or consider the changes made by the older automation on the object records and design the new process accordingly. If there are multiple automation like workflows and apex triggers running on a single object, it may become difficult to define the order and verify the results of record changes for that object.

3. Restrict the total number of actions in a process:

While designing and creating a process in Salesforce Process Builder, it is recommended to create a lesser number of actions in a process and try to accommodate multiple requirements in a single action in order to avoid reaching org limits like the number of DML statements or total CPU usage. For instance, you can update multiple fields in an object in one action rather than creating individual actions for individual fields.

4. Single process for 1 object:

It is better to combine the record change processes on an object in a single master process rather than having it split over multiple ones as a combined process helps you to determine the results accurately, define order in which the actions needs to be applied on the object and also helps you to restrict the total number of queries running on account level helping to avoid hitting org usage limits. Combining multiple processes into one also helps to avoid process failures due to actions overwriting previous changes made to a field.

Example: If there are multiple processes running on the same field, the order in which they update the field may lead to the success/failure of other processes running on that field.

5. Look out for infinite loops in Salesforce Process Builder:

When you are dealing with multiple processes, you should stay careful with infinite loops as 2 independent processes may get into an infinite loop and trigger your org limits.

Example: A create record action in Process 1 can trigger Process 2 which contains an action of update record which is the trigger for Process 1. This may lead to an infinite loop which will eventually lead to a breach of org limits.

6. Lookout for action timelines:

Salesforce Process Builder can perform actions immediately or even on a schedule. Certain immediate actions taken on an object may disqualify it for another scheduled action. While designing and creating a process, you need to keep in mind the timeline of the actions that will be followed across the processes and design it to avoid any conflicts.

7. Use scheduled actions to access external data:

It is recommended to create a separate transaction whenever Salesforce needs to access data from an external tool.

Example: If a process updates records in Salesforce and then access external data in the same transaction, it may result in a failure. The recommendation in such cases would be to use a scheduled action to access the external data after the record update transaction.

8. Use case testing in Salesforce Process Builder:

There can be multiple use cases where one action can affect other processes that are part of the system. So, it is recommended to do a thorough round of testing of the process and affected fields before deploying in production in order to avoid any conflicts with other processes.

9. Use a test environment:

All the processes should be first built in a test environment. It is never justified to build directly in Production as there may be repercussions of a process on other processes that may even hurt business continuity. It is recommended to build and test the logic in a test environment thoroughly and then deploy it in production.

10. Follow a naming convention in Salesforce Process Builder:

It is advised to follow a proper naming convention and add descriptions wherever applicable while creating a process to easily identify the functionality and category of the process.

Process Builder is one of the most useful tools which is supposed to make the processes easier for users to build and also reduce the workload by bringing in automation. If all the best practices mentioned above are followed correctly, Process Builder will make your life easy. However, if the best practices are not followed properly, it ends up doing more harm than good. It is always advised to follow the best practices and test all scenarios thoroughly before handing over the reins to automation.