You can use the dynamic wait time to set a custom wait period using Jinja. You can use some project metrics, aggregates, trigger event attributes, or personalization.

Typical usage of the dynamic wait time is to spread or throttle the campaign execution over some time period using the[ random number generator](🔗). E.g., to spread the send approximately within 60 minutes, you can use the`{{ range(0,60) | random }}`.

If the Wait time is set to hours, the number is rounded down (to an integer). For example, when you calculate 1.8 hours wait, the Wait node waits only 1 hour. If you want to round up, you can use the Jinja function [round](🔗) (can accept "ceil", "floor," or "common" parameter):

Wait `{{ ((event.departure_time - time) / 3600) | round("ceil") }}` hours

The way that the **specific time period** in wait nodes works is that it takes the calendar definition of periods. For example, if you set 1 month starting from June 15th, the result will be triggered on July 15th. When the calendar day doesn't exist in the target month, it adds fewer days. For example, January 31st + 1 month would be February 28th. In sum, it's always one calendar month - anywhere between 28 and 31 days in order to achieve the same date the specified number of months later. The same calendar logic applies for days, weeks, and years.

The wait node does not wait at all if the wait value is zero or lower (executes the following node right away).

1668


Delivery of an SMS campaign can be either **successful** or **unsuccessful**. Bloomreach Engagement tracks this information as an attribute of the `campaign` events.