Node List
Delay
Learn about delay node in workflow and how to use it to add wait between workflow steps.
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.
There are 3 types of delay types available: Fixed (fixed for all users), Dynamic (Passed in trigger payload), Relative (relative to a future timestamp, e.g. 10 minutes before task due time).
Fixed
Fixed
Fixed delay is defined in your workflow form as 
Some examples of fixed delay are:
*\*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. 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
Dynamic
In case of dynamic delay, delay duration is computed using the data from trigger payload. 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:
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:-
General format for duration key at parent level is
.duration_key -
If the duration key is a nested event property key like shown below, enter it in the format
.appointment_details.time
- 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
xxdxxhxxmxxs, where d = day, h = hour, m = minutes and s = seconds
- an integer like
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
Relative
Relative delay is calculated based on a future timestamp. e.g., 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.
- Timestamp at the parent level:
.timestamp - If the dynamic interval is set as recipient property:
."$recipient".interval