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.
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.
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).