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.

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:

3. Value - Value can be fixed 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.

Adding conditions on multiple events

You can add condition on multiple events separated byOR 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. 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.