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:
- allows a full bypass at the Triggering PB level, so only one PB gets evaluated, and you don't need to add bypasses in any other PB or even any other decision diamonds - so effectively one bypass, or maybe two, per Object.
- doesn't touch the record, so effectively does a full bypass
- has this semi-annoying notification which is both a blessing and a curse, but I think they have "no action" on the roadmap.
Process Builder Structural 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.
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:
- one PB for create actions
- one PB for create/edit
- one PB for just time-dependent stuff
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
- 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 case 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.|