Delay

Delay node halts the workflow for a given time period before moving to the next step. It is best used in case of reminders and re-engagement notifications where you want to bring back user to the product after a period of their last action.

You can either add a Fixed delay or Dynamic delay in your workflow. Dynamic delays are computed using data in your event properties and can vary for each user. A good example of dynamic delay could be an event reminder whose frequency is set by the user.

Fixed delay

Fixed delay is defined in your workflow form as **d **h **m **s and it delays the workflow for a fixed duration 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 24 hours 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 reminders need to be sent before the event or task due date.

For instance, you might want to send a reminder one day before an interview date. In such scenarios, the reminder schedule can also be user-defined, resulting in variable delays per user. Consider the example of Google Calendar, where each user sets their own reminder schedule for meetings—some opt for reminders 10 minutes before, while others prefer 30 minutes before. Dynamic delays accommodate these individual preferences seamlessly.

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 .appointment_details.time.

properties = {													  
  "appointment_details": {  
    "time": "2024-03-02T20:34:07Z",  
    "location": "1775 Stanford Ave, Menlo Park, CA 94025"  
  }

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 in the logs

Relative delay

Relative delay is calculated based on a future timestamp. For example, sending a reminder 30 minutes before a task's due time, where task_due_time is a key in the trigger payload. It consists of three key components:

• Interval: The delay from the future timestamp, formatted as xxdxxhxxmxxs (e.g., 30m for 30 minutes). This can be:
  • Fixed (e.g., always 30 minutes before).
  • Dynamic, where the value is retrieved from the payload (e.g., in Google Calendar, users can set reminders for 10 or 20 minutes before an event).
• Before/After: Determines whether the interval is subtracted (before) or added (after) to the timestamp.
• Timestamp: An ISO-8601 format datetime (e.g., 2024-03-02T20:34:07Z), which must be in the future.

Dynamic Interval & Timestamp must be passed as a JQ-expression. Examples:

• Timestamp at the parent level: .timestamp
• If the dynamic interval is set as recipient property: ."$recipient".interval