Wait Until is a conditional branch which halts the workflow until either the branch condition is met or the maximum wait duration is reached. It is most used for cases where sequential notifications need to be sent to users based on certain conditions, such as payment or task reminders.

​
How wait until works?

Wait Until has 2 branches- Condition and Max time. The user proceeds through the branch that is satisfied first.
  1. Condition: User proceeds through this path when a condition is met, such as an event being triggered, user properties, or the event properties that initiated the workflow. In case of payment reminder, condition could be the event trigger of user completing payment.
  2. Max time: This is the maximum time the user can wait for the condition to satisfy until the next step should be executed. If a person reaches the maximum wait time without achieving any other conditions, they’ll progress through this branch.

Wait Until - Payment Reminder example

You can incorporate multiple Wait Until nodes in sequence to create a multi-step notification journey, where each notification is sent based on a specific condition being met.

​
Conditions

You can add conditions on event properties, user properties, and action / event performed by user. It’s important to note that conditions are evaluated when the workflow execution reaches “Wait Until” node, meaning any events performed before this point will not satisfy the condition branch. Except for max time branch, all other branches are condition branches. To setup a condition, you can select the type of the condition and the expression defining the condition.

​
Type: Event is performed

Here, the branch condition satisfies when a given event is received during the wait time. This type of condition is ideal for scenarios like reminders, where you want to avoid sending a reminder if the necessary action is completed within the wait time. You can define the event name and apply conditions on event properties to filter and identify the exact event associated with the workflow. For instance, in a booking reminder scenario, If a user has multiple bookings, you can match the booking ID of the cancellation event with the booking ID of the original event to ensure the correct reminder is cancelled.

​
Adding filter on event properties

Property condition is constructed as key, operator and value. You can add multiple conditions separated by AND, OR.
  1. Key: It is the variable key in your wait until event properties.
  2. Operator: you can use any of the below operators to compare key and value:
OperatorDescription
==Key is equal to value. This is a case-sensitive check.
!=Key is not equal to value. This is a case-sensitive check.
>Key is greater than value. Can be applied to integers, float values, or epoch timestamps.
>=Key is greater than or equal to value. Can be applied to integers, float values, or epoch timestamps.
<Key is less than value. Can be applied to integers and float values.
<=Key is less than or equal to value. Can be applied to integers and float values.
containsKey should be a substring or a list item in an array.
not containsKey should not be a substring or match any list item in an array.
is emptyEvaluates to true if the key is missing, an empty string, or has a null value.
is not emptyKey should be present and should not be an empty string or null value.
intersectsEvaluates to true if any value in the left array matches any value in the right array. Useful for checking overlaps between arrays.
not intersectsEvaluates to true if no values in the left array match any values in the right array. It could be used in case of checking or filtering out any overlaps between arrays.
  1. Value: Value can be fixed (static value) or dynamic (evaluated dynamically from workflow data).

​
Fixed values

Fixed values can be added as:
  1. string- enclose within double inverted commas as "string"
  2. number- 1, 1.2
  3. boolean- true, false

​
Dynamic values

Dynamic values are evaluated based on the data available at the node input along with actor, recipient or tenant properties. Refer below table for types of dynamic values and their respective syntax.
Data TypeDescriptionReferring this property in condition
Input PayloadIncludes data from your trigger payload and any data modified or added by nodes such as data transform, batch/digest, or webhook/fetch nodes before the branch node.Directly specify as key with no prefix
ActorActor properties. In the case of an event trigger, distinct_id works as both actor and recipient. For an inline workflow trigger, it is the distinct_id in the actor object.Add as $actor.<property_key>
RecipientRecipient properties. It is the distinct_id in your event trigger or the key value defined in override recipient field. For an inline workflow trigger, it is the distinct_id in the recipient object.Add as $recipient.<property_key>
TenantTenant properties. These include all properties of the tenant_id in your workflow trigger.Add as $brand.<property_key>

​
Adding conditions on multiple events

You can add condition on multiple events separated by OR operator. Evaluation will pass if any of the conditions separated by OR is true.

​
Max time

This branch will be executed if none of the condition branches are satisfied. This is where you’ll add your send nodes in case of reminder workflows. You can either add a Fixed delay or Dynamic delay in max time. Dynamic delays are computed using data in your event properties and can vary for each user. A good example of dynamic delay could be reminders where frequency is set by the user.

​
Fixed delay

Fixed delay is defined in your workflow form as **d **h **m **s and it adds a fixed delay for all users. Some examples of fixed delay are:
  • Sending multiple payment or activity reminders at predetermined intervals. For instance, sending three payment reminders spaced 2 days apart from the last due date.
  • Implementing conditional sends across multiple channels. e.g., sending an approval notification via Inbox and scheduling an email to be sent one hour later if the approval is not received. Smart channel routing is a better approach to solve this use case.

​
Dynamic delay

In case of dynamic delay, delay duration is computed using the data from your event properties. Dynamic delays are helpful for reminders where the schedule is dictated by the user or when notification needs to be sent before the event or task due date. Imagine you need to send task completion reminders, where users can specify a reminder frequency, such as every 6 hours until the task is finished. This frequency can differ for each task and user. Dynamic wait times effortlessly adapt to these unique preferences. You can add duration key as a JQ-expression. Below are some examples of how to add duration key in JQ format:
  1. General format for duration key at parent level is .duration_key
  2. If the duration key is a nested event property key like shown below, enter it in the format .reminder.frequency
{
  "reminder": {
    "frequency": "6h"
  }
}
Your duration key variable can be computed to either:
  • An ISO-8601 timestamp (e.g. 2024-03-02T20:34:07Z) which must be a datetime in the future, or
  • A relative duration unit, which can be
    • an integer like 50, considered as duration in seconds.
    • an interval string defined as **d **h **m **s, where d = day, h = hour, m = minutes and s = seconds
When the duration key specified is missing, or resolves to an invalid value, workflow execution will stop and corresponding error will be logged.