Final considerations for building with a Process Builder

Before closing this chapter, let’s look at the things we need to take into consideration when building automation using a Process Builder.

The first suggestion is to use one automation tool for each object because it becomes very difficult to predict when actions will take place if you have a Process Builder, Apex triggers, and workflow rules active at the same time.

When replacing a workflow rule or an Apex trigger with a Process Builder, remember to deactivate them before activating the Process Builder, otherwise you may get unexpected results, such as the record being overwritten several times or multiple email notifications being sent (we don’t want to spam our precious users).

Moreover, use only one record-change triggered process per object. That way, you will have an idea of what’s happening behind the scenes, be able to predict the order of execution, and avoid hitting the platform’s governor limits.

Transaction governor limits are an important part of the developer life cycle because they state how many operations Apex code can perform when a database transaction is done (that is, a record is created/updated/deleted). Since each Salesforce organization lies with other Salesforce organizations in the cloud, Salesforce has to ensure that no organization consumes too many resources so that the other organizations suffer (an organization can become unstable or slow). By limiting the resources each transaction can consume, Salesforce attains better performance and reduces the chance of system failures.

Governor limits are more than this, but by referring to our scope, we can define the following limits (as of Winter ’20 release):

• Total number of SOQL queries: 100
• Total number of records retrieved by SOQL queries: 50,000
• Total number of DML statements (that is, CRUD database operations): 150
• Total number of records processed as a result of DML statements: 10,000

In a Process Builder, a SOQL query is executed on Update Record actions (which can return one record if the update is done on the trigger object or several records if we are getting, for example, all the cases for a given account) and a DML is executed on Quick Actions, Record Creations, or Update Records actions (for the latter, if you update all the cases for a given account, we will have 1 DML, but several records processed on that DML).

This means that it is good practice to combine actions when possible: don’t create different Record Updates to update the same object; instead, create one Record Update action that updates all the required fields for the same record.

For a complete list of execution governor limits, please refer to Salesforce Help at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm.

Pay attention and avoid infinite loops; for example, Process A triggers Process B, which creates a new record that triggers Process A, and so on. This is a possible cause of a governor limit outbreak.

Before moving on to the next chapter, take a look at the Automation Champion’s Process Builder blog at https://automationchampion.com/learning-process-builder/. From there, you will have access to tens of examples and countless hints that can empower your Process Builder knowledge and expertise.

Process Builder is a powerful tool that can leverage process automation in your organizations and create exceptions in certain situations. This tool should cover all your needs. There’s no doubt that Salesforce will push this technology further in its next releases to allow administrators to write complex automation, thus reducing the need for custom development (we’ll talk about this in more detail in Chapter 15, The Coding Approach).

Summary

In this chapter, we’ve dealt with the Process Builder, a reliable, efficient, and featureful process automation tool that is meant to provide the same features that workflow rules provide, but with enhanced abilities.

Here, we’ve seen how we can create a new process related to object and trigger events and define criteria to execute immediate and scheduled actions that span from simple record updates to custom notifications or Apex classes.

We also looked at how we can manage Process Builder instances by cloning them and creating new versions. Finally, we looked at some best practices for aligning an action’s execution with Salesforce governor limits.

In the next chapter, we’ll inspect Flows, which provide even more automation so that we can collect, create, and update Salesforce data using automated actions or user interface forms.