ARCHIVED - Process Builder Structural Conventions

Process Builder is old, decrepit, and deprecated.
You can't create new ones, and if you're editing old ones you should be migrating to Flows instead.
This is ARCHIVED content, will never be updated, and is here for history reasons.

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:

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