Process Builder Conventions

All Naming Conventions Are <a href="https://www.ietf.org/rfc/rfc2119.txt“>RFC 2119</a> and <a href=”https://tools.ietf.org/html/rfc6919">RFC 6919</a> compliant.

General Conventions

1. If there are APEX triggers firing on an object, Process Builder SHOULD NOT be used. *1
2. If Process Builders existed before building the APEX triggers, the Process Builders SHOULD be replaced by APEX triggers and classes.
3. Process Builders REALLY SHOULD NOT fire on, update, or otherwise reference, Person Accounts.
4. Process Builders REALLY SHOULD NOT perform complex operations on records that can be massively inserted/updated as a routine part of organization usage.
5. Process Builders MUST NOT call a Flow if firing on an object that can be massively inserted/updated as a routine part of organization usage.
6. Process Builders execution SHOULD be limited to the exact cases where they are needed. *2. In all cases, a consultant SHOULD limit the number of process builders executing on an object.

Structural Conventions

1. Generally, a consultant SHOULD build Invocable Process Builders, and Invoke them from one single Process on the trigerring Object.
   • This is by opposition to creating one process builder by task.
   • Invokable process builders cannot be used to trigger time-dependent actions.
2. Process Builders generally SHOULD NOT use the “no criteria” option of the Decision Diamonds.
3. Whenever possible, multiple Process Builders on an object should be migrated to a single Process Builder, with different actions evaluated one after the other. This is now officially mandated by Salesforce.

Naming Conventions

1. A Process Builder name SHALL always start by PB, followed by a number corresponding to the number of process builders in the Organization, followed by an underscore.
   a. If the Process Builder Triggers other Process Builders, it SHALL always start by TPB instead.
   b. If the Process Builder is Invoked by other Process Builders, it SHALL always start by IPB instead.
2. The end of a Process Builder name SHOULD always be:
   • the name of the object, in the case of a Triggering Process Builder (TPB)
   • the action carried out, in the case of an Invoked Process Builder (IPB)
   • the trigger and action, in the cas of a standalone Process Builder (PB)
3. A Process Builder name COULD contain either C, CE, or CES wrapped by underscores, to show if the PB triggers on Creation, Creation and Edition, or Subsequent Modifications that Fill Criteria. The default assumed setting is CE if none is written. *3
4. All Process Builder Triggers MUST have a description detailing their purpose.
5. A Process Builder Decision Diamond SHALL be named after the criteria that are used in the most precise manner possible.
6. A Process Builder Action SHALL be named after the action being carried out in the most precise manner possible.

*1 This is a best practice, but it should be noted that for smaller organizations, triggers and process builders may coexist on the same objects…
*2 Note that contrary to Workflows and Validation Rules, you cannot add a bypass to a Process Builders, as you cannot target User fields on decisions. As sucj, limiting the scope of execution of the process builder is paramount…
*3 This is the default setting for Process Builders. To activate CES, one must click on “advanced” on the Decision diamond.