Trigger selection

In the previous section, we looked at the Process Builder designer and all the blocks that we need to create a new instance of a Process Builder. The first step is creating a triggering condition. To do so, we need to use the + Add Object button to open up the triggering conditions modal. The following screenshot shows the Process Builder’s trigger selection for the record changes Process Builder:

The Start the process* radio buttons look like the same options we had on the Workflow rule definition page, where we could define the triggering conditions, whereby a record may trigger the given workflow (if you don’t remember this, please refer to Chapter 11, Automation with Workflows) exception that was made for the created, and any time it’s edited to subsequently meet criteria option that’s available later on in the configuration process.

To set everything up, perform the following steps:

1. Select the object type.
2. Set the Start the process option (this triggers the process when the record is created and/or updated).
3. Flag the Recursion – Allow process to evaluate a record multiple times in a single transaction? checkbox if you want the same Process Builder to be evaluated more then once in a single save transaction (up to five times per transaction). By flagging this checkbox, any record change that is executed after this Process Builder has completed its actions (there is no reason for this Process Builder to update the record so that another Process Builder can be triggered) can trigger the same Process Builder repeatedly until the recursion level has been reached (the five-times limit). Simply put, a Process Builder can trigger itself up to five times if this checkbox is flagged.

Every time the Process Builder is executed, it will handle a new version of the record by taking the modifications of the automations that preceded it into account.

When dealing with platform events and selecting the A platform event message is received option on the New Process modal, the subsequent form changes slightly:

Creating a new Process Builder to handle platform events

You can check how the form has changed by clicking on the + Add Trigger button (which replaces the + Add Object button), which displays the following options:

Process Builder Trigger selection for platform events

In this example, a Coffee Machine Alert platform event (which may tell Salesforce that we have run out of water) must be matched with a contextual Salesforce object, which, in our scenario, is an Asset object. The match is made using the Serial Code field on the platform event and the Serial Number on the Asset object.

In this case, we don’t have a Start the process radio button since the platform event cannot be updated. For the same reason, it isn’t possible to loop on the same Process Builder more than once.

If the matching conditions that should match a Salesforce object to give the platform event a context on the CRM find none or more than one related Salesforce objects, the Process Builder fails (it is not possible to relate none or multiple objects to a given platform event).

If we were building an invocable Process Builder, the trigger form would have been even simpler:

Process Builder Trigger selection for the invocable type

When the process is invoked by another process, it only carries out the object type it is referring to.

Now, we need to sort out the criteria definition.