IDs
IDs used in criteria must be 18-digit IDs. These are standard in Lightning record-page URLs now, so this mistake isn’t as easy to make as it used to be, but it can be very vexing to identify and fix.
Scheduled Actions in Process Builder
Process builder allows you to schedule actions immediately (usually in response to record creation or specified changes to a record), as well as scheduling actions in the future, either relative to the date or time of the process firing, or based on some fixed date on a record: a membership start date, for instance.
These scheduled actions can remain sensitive to record changes, which is a really useful tool. But unfortunately, there’s a lot of small print that you should read and understand before getting too ambitious with your scheduled actions. It’s complicated enough in stable circumstances, but things can really go off the rails if you need to make any changes to your process after it has scheduled some actions. We’ll get to that in a bit, but for now let’s look at the basics.
For the purposes of this example, we’re sending a series of membership payment reminders. These memberships are tracked as opportunities, and the due date is the Opportunity Close Date. The first of these reminders will be triggered when you set the opportunity stage to “Invoiced.” This is the criteria that is set in the blue diamond in your process. Using scheduled actions, a second will be sent 30 days before the Close Date, and a “final notice” will go out on the Close Date itself.
Things to know:
- If a scheduled action is set to occur in the past, it will be fired as soon as possible. In the case of our example, if you set the record to “Invoiced” 29 days before the close date. Your first reminder and your 30-day reminder will go out within minutes of each other, which is not a good look. Your process should probably reflect this if there’s any chance that your human (or other automated) processes will allow this to happen. So, you might have a separate step that looks at how far out the close date is when the process fires, before setting the 30-day scheduled action.
- According to the documentation, the execution date for scheduled actions will adjust for changes in that base date on your object. So if you make the Close Date 10 days later, then the 30 day reminder will adjust accordingly. This will happen (according to the documentation) whether your process is triggered only on record creation, or on creation or change, and even if the process version is deactivated.
- If the process is based on record change or creation (not just on creation, or invoked by another process), the scheduled action’s execution will be continue to depend on the criteria you set for initial execution. Which (seemingly) works great for us here, because if the Opportunity Stage changes to “Paid” (or “Cancelled” or whatever), then we don’t want the reminder going out. All else equal (hold that thought. . .), this works great for us. If the payment is still pending on the reminder dates, the reminder emails go out. If the payment isn’t pending, then then reminders don’t go out.
Here’s the catch:
If the version of the process builder flow that initiated the scheduled actions is no longer active, record changes will no longer have the intended effect on the execution of the scheduled action. This is a big deal, because editing a process builder flow means creating a new version of the process, and activating the new, edited version deactivates the old. Any reminder emails scheduled by that process prior to the deactivation will be sent on schedule, without checking back to see if the Opportunity is still set to Invoiced.
There do seem to be some exceptions to this – for instance, Record Update actions provide the option of adding criteria in the action step itself (in addition to criteria in the blue diamond to the left that kicks off the string of actions, immediate and scheduled.) These criteria appear to continue in place after a process builder process has been deactivated, based on a limited sample of real-world scheduled actions.
Hard-won experience tells me that no matter how perfect and eternal, and bulletproof your process builder flow appears to be, it will need updating at some point, and sooner than you think.
So!
If you plan to use contingent scheduled actions in process builder, make sure you think through the implications of deactivating the flow.
In the case of the payment reminder emails example, one way to program around this pitfall is to make all of the email sends based on a record change, and make those record updates your scheduled actions. You can add a new picklist field to the opportunity called Payment Email, with three values: First, Reminder, and Final*. Then set up separate process rows, all of which should only fire when the fields have changed to meet the criteria:
When Opportunity.Stage is set to Invoiced, have
- an immediate action that sets the Payment Email to First
- a scheduled action for 30 days before close date that sets Payment Email to Reminder if the Stage = Invoiced**, and
- a scheduled action for the actual close date that sets Payment Email to Final if the Stage = Invoiced**
If these are all part of a single process builder process, it either needs to be recursive (so that it can re-evalute after the record changes), or this row needs to continue to the following row so that the first email gets sent properly
Then set up three additional rows in the process:
- If Stage = Invoiced, and Payment Email = First, send the First email
- If Stage = Invoiced, and Payment Email = Reminder, send the Reminder email
- If Stage = Invoiced, and Payment Email = Final, send the Final email
Notes:
This is a back-of-envelope type sketch of a process, rather than a full how-to, so some steps may be, well, sketchy. I hope you’re able to work through it. Please let me know, and I’m happy to help if
This back-of-envelope sketch doesn’t include any safeguards for Opportunities that are scheduled as Invoiced within the 30 days, which you’d probably want to build in as well.
* I’d recommend setting your Payment Email field to be read-only for most users, or simply not available on the page layouts. You don’t want anyone accidentally triggering extra emails to your members.
** While this extra criteria seems redundant in terms of preventing unwanted emails from going it, it preserves the Payment Email field in the state that reflects when the member renewed (or cancelled) their membership, which can be useful in analyzing the effectiveness of your efforts.