Process Builder Conventions

Naming and structural conventions related to Process Builder

Process Builder Bypass

Normally we put bypasses in everything (workflows, validation rules, etc). Process builders especially are interesting to bypass because they're still SLOW AS HELL and they can be prone to unforeseen errors - specifically during data loads.


Plus if you have process builders sending emails you probably want to skip them when you're loading data massively.
A few years ago I didn't find a solution that suited me. A yea or so they activated systems labels for PB, so you can search for the custom setting like in WF - but you couldn't go next element, so you had to add the bypass, in formula mode, to every element. Taxing and costly in hours, plus you had to use formulas to everything.


Here you set it once, in every TPB, and then you have a working bypass for every process builder ever. Low cost, easy to maintain, and allows deactivation on mass loads or other operations where you don't want those things firing.

 

Ok so there's the usual, recommended Bypass Custom setting that I write about in my best practices. I added a PB there

I created a notification type

which then allows you to do this:

I would rather it's "no action" but that doesn't exist. so in the meantime, this:

Process Builder Structural Conventions

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 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 triggering Object.
❍ This is by opposition to creating one process builder by task.
❍ Invocable process builders cannot be used to trigger time-dependent actions, meaning you will probably end up with:

2. Process Builders generally SHOULD NOT use the "no criteria" option of the Decision Diamonds. There is always at least one sanity check to do
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.

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

 

Process Builder 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 case 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.
Type Name Description
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.