Wait Until

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.

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.

Currently, only the Event is Performed condition is supported, with plans to add support for other types of conditions in the future.

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.

In Event performed condition, you just have to define the event name that, when received during the wait duration, will satisfy the condition branch.

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. For example, 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 usecase.

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.

properties = {													  
  "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.