The Start Timer Action can be used to run Action Chains at designated times. Timers can be set to fire some number of time units from the moment they're set or at a specific DateTime, and they provide options to enforce TCPA compliance as well. 

For example, if configuring a Timer to send a reminder to a customer five minutes before their selected call time, this can be done as follows by utilizing the SUBTRACT_FROM_DATETIME function:

But sometimes, that reminder may be set to send outside of TCPA-compliant hours. In order to comply by TCPA restrictions, Timers have the option to pass in a TCPA compliant Availability Schedules from the customer's timezone:

From there, under If time is not available, you can define how the Timer will fire instead:

Once you have inserted a Start Timer Action into your Action Chain, you can nest Actions with it by clicking on the '+' icon to its right:

Any number of Actions can be nested within a Start Timer Action. These Actions will be taken if and only if the Timer is fired, and they will be taken from top to bottom in the order they were listed, as if they were a self-contained Action Chain.

Best Practices using Timers

• When using Timers for customer reminders, it is always good practice to comply by TCPA restrictions. Check out TCPA for more information.
• Timer Keys must be unique across the application when creating Timers.
• It is good practice to use the Stop Timer Action when the Timer is no longer needed in the customer Journey. Don't rely on session management to cancel the timers.
• Build out Timers that are tied to Events. This enables you to have full control over the inputs and management of your Timers.
• Timers only have access to data that is tied to the client state. If a Timer is created in an Event, data cannot be passed from the Event namespace to an Action in the Timer. If passing data from the Event namespace, data must be stored in a temporary variable and then passed to the Actions associated with the Timer.