- If there are APEX triggers firing on an object, Process Builder SHOULD NOT be used. *1
- If Process Builders existed before building the APEX triggers, the Process Builders SHOULD be replaced by APEX triggers and classes.
- Process Builders REALLY SHOULD NOT fire on, update, or otherwise reference, Person Accounts.
- Process Builders REALLY SHOULD NOT perform complex operations on records that can be massively inserted/updated as a routine part of organization usage.
- 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.
- 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.
- 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.
- Process Builders generally SHOULD NOT use the “no criteria” option of the Decision Diamonds.
- 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.
- 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
b. If the Process Builder is Invoked by other Process Builders, it SHALL always start by
- 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)
- A Process Builder name COULD contain either
CESwrapped by underscores, to show if the PB triggers on Creation, Creation and Edition, or Subsequent Modifications that Fill Criteria. The default assumed setting is
CEif none is written. *3
- All Process Builder Triggers MUST have a description detailing their purpose.
- A Process Builder Decision Diamond SHALL be named after the criteria that are used in the most precise manner possible.
- A Process Builder Action SHALL be named after the action being carried out in the most precise manner possible.
|Process Builder||TPB01_Opportunity||This Process Builder invokes all invocable Opportunity Process builders|
|Process Builder||IPB01_SetOwnerTarget||Copies over target from Owner to calculate monthly efficiency|
|Process Builder||PB01_ContactBirthdatEmail||Sends a birthday email on the contact’s birthday.|
|Decision Diamond||Status is “Approved”||#N/A|
|Action||Sets Contact Scoring to 10||#N/A|
|Process Builder (possible variation)||TPB01_Opportunity||This Process Builder invokes all invocable Opportunity Process builders. Also Handles various actions such as birthday emails.|
*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.