The Delay Node pauses a workflow for a specified duration before allowing execution to continue to the next step. It supports both fixed durations (a static amount of time) and dynamic dates (a target date/time resolved from workflow data at runtime). The Delay Node is the primary mechanism for introducing intentional wait periods into automated processes.

When to Use

Use a Delay Node when your workflow requires:

A cooling-off or waiting period between steps (e.g., wait 24 hours before sending a follow-up reminder).
Scheduling an action for a specific future date/time derived from form data (e.g., send a welcome email on an employee's start date).
Introducing a buffer before an external system is polled or a dependent step begins.
Delaying notifications or escalations to a time that makes sense for the business process.

Configuration

Delay Type

The node supports two delay strategies:

Delay Type	Description
Fixed	Wait for a static duration from the current moment — configured as days, hours, and minutes. The delay is always relative to "now."
Dynamic	Wait until a specific date/time resolved from the Data Center at runtime. Optionally, add or subtract a fixed offset from that date.

Fixed Delay

A fixed delay pauses the workflow for a specified number of days, hours, and minutes from the moment the node executes. All three components are combined into a single duration.

Field	Description
Days	Number of days to wait.
Hours	Number of hours to wait.
Minutes	Number of minutes to wait.

Example: A delay of 1 day, 2 hours, and 30 minutes pauses the workflow for exactly that duration from the moment it's reached.

Dynamic Delay

A dynamic delay waits until a target date/time that is resolved from the Data Center at runtime. This is useful when the wait period depends on data submitted by the user or returned by an earlier step.

Field	Description
Data Centre Key	A Data Center expression that resolves to a date string (e.g., the start date submitted in a form).
Date Format	The expected format of the date string (e.g., `YYYY-MM-DD HH:mm:ss`). The system uses strict parsing — the date must exactly match this format.
Use Fixed Offset	When enabled, the resolved date is adjusted by adding or subtracting the fixed delay values (days/hours/minutes) configured on the node.
Fixed Type	When offset is enabled — Add Time adds the duration to the dynamic date, Subtract Time subtracts it.
Fallback Type	What to do if the dynamic date cannot be resolved or is invalid.

Timezone handling: If the date includes a timezone offset (ISO 8601 format), the system preserves the original timezone. For all other formats, the application's configured timezone is applied.

Fallback Behavior

When the delay type is Dynamic and the resolved date is invalid (unparseable, empty, or doesn't match the format), the fallback type determines what happens:

Fallback Type	Behavior
Skip (default)	The node is skipped — the workflow does not continue to the next node.
Complete Immediately	The node completes instantly — the workflow continues to the next step with no delay.

Past Date Handling

If the delay type is Dynamic and the resolved date is already in the past, the node completes immediately and the workflow proceeds without waiting. This also applies when a fixed offset is used and the adjusted date falls in the past.

Progress Path

The node can optionally be hidden from the end-user progress tracker if the delay is an internal implementation detail that shouldn't be visible.

How It Works at Runtime

Fixed Delay

The system calculates the total wait time from the configured days, hours, and minutes.
The workflow pauses and is scheduled to resume after the specified duration.
Once the wait time passes, the workflow automatically continues to the next node.

Dynamic Delay — Future Date

The Data Center expression is resolved to a date string.
The date is parsed using the configured format.
If a fixed offset is enabled, it is added to or subtracted from the parsed date.
If the resulting date is in the future, the workflow pauses and resumes when that date arrives.

Dynamic Delay — Past Date

If the resolved (and optionally adjusted) date is in the past, the node completes immediately and the workflow proceeds without waiting.

Dynamic Delay — Invalid Date

If the date cannot be resolved or doesn't match the expected format, the fallback type is applied — either skip the node or complete immediately.

Best Practices

Use fixed delays for simple, predictable wait periods like "wait 1 hour before sending a reminder" or "wait 3 days before checking status."
Use dynamic delays when the wait depends on business data — for example, triggering an onboarding workflow a certain number of days before an employee's start date.
Choose the fallback type carefully. Use "Complete Immediately" when the workflow should continue regardless (the delay is nice-to-have but not critical). Use "Skip" when proceeding without a valid date could cause problems downstream.
Use the fixed offset with dynamic dates for relative scheduling — for example, "2 days before the event date" (Subtract Time) or "1 hour after the submission date" (Add Time).
Be precise with date formats. The system uses strict parsing, so 2025-01-15 will not match YYYY-MM-DD HH:mm:ss. Ensure the format exactly matches the date strings your workflow produces.
Account for past dates in your workflow design. If the dynamic date might already be in the past when the workflow reaches the Delay Node (e.g., a retroactive request), the node will complete immediately. Design your downstream logic accordingly.
Use ISO 8601 format for timezone-aware dates to avoid ambiguity. For other formats, the application's timezone setting is applied.