Delay — Examples — BizFirstAI

Example 1 — 24-Hour Onboarding Reminder

After a new user registers, send a welcome email immediately, then wait 24 hours before sending a "getting started" follow-up email. The durable delay ensures the workflow survives any server restarts overnight.

{
  "node_type": "Delay",
  "name": "Wait24HoursBeforeFollowUp",
  "config": {
    "delay_type": "duration",
    "duration_ms": 86400000
  }
}

Outcome: The workflow pauses for exactly 24 hours (durable, since 86,400,000 ms vastly exceeds the 30,000 ms threshold). The follow-up email node runs when the delay expires on the success port.

Example 2 — Retry Cooldown Between API Attempts

In a retry loop, pause for 30 seconds between each failed API call attempt. The delay interval is short enough to be handled in-process.

{
  "node_type": "Delay",
  "name": "RetryCooldown",
  "config": {
    "delay_type": "duration",
    "duration_ms": 30000,
    "in_process_threshold_ms": 60000
  }
}

Outcome: The 30-second delay is handled in-process (below the 60,000 ms threshold). After the cooldown, the loop iteration retries the API call. Up to 3 retry cycles add a maximum of 90 seconds of wait time.

Example 3 — Wait Until Contract Start Date

A contract management workflow creates a contract record immediately but must wait until the contract's official start date before activating the subscription and sending the first invoice.

{
  "node_type": "Delay",
  "name": "WaitForContractStartDate",
  "config": {
    "delay_type": "until",
    "until_expression": "{@ var.contractStartDateUTC }"
  }
}
// var.contractStartDateUTC = "2026-09-01T00:00:00Z"

Outcome: The workflow suspends durably until September 1st, 2026. On that date, the success port fires, and the subscription activation and invoice generation nodes run. The waiting port fires immediately when the suspend is created, allowing an operator dashboard to show this workflow as "pending start date".

Example 4 — Dynamic Exponential Backoff Delay

A retry mechanism uses exponential backoff — the delay doubles with each retry attempt. A CodeExecute node computes the interval and stores it in var.retryDelayMs; the Delay node reads it dynamically.

// CodeExecute: calculate exponential backoff
// result = Math.min(1000 * Math.pow(2, retryCount), 60000);
// VariableAssignment: retryDelayMs = output.CalcBackoff.result

{
  "node_type": "Delay",
  "name": "ExponentialBackoffDelay",
  "config": {
    "delay_type": "duration",
    "duration_expression": "{@ var.retryDelayMs }"
  }
}

Outcome: Retry 1: 2,000 ms (in-process); Retry 2: 4,000 ms (in-process); Retry 3: 8,000 ms (in-process); Retry 4: 16,000 ms (in-process); Retry 5: 32,000 ms (durable). The delay adapts automatically based on the retry count variable.

Example 5 — 7-Day Cancellation Cooling-Off Period

When a customer submits a cancellation request, regulations require a 7-day cooling-off period before the cancellation is processed. During this period, the customer may withdraw their request via the cancelled port.

{
  "node_type": "Delay",
  "name": "CoolingOffPeriod",
  "config": {
    "delay_type": "duration",
    "duration_ms": 604800000
  }
}
// success port  → process the cancellation (7 days elapsed, no withdrawal)
// cancelled port → customer withdrew the request — restore subscription
// waiting port  → log that this cancellation is in the cooling-off period

Outcome: If the customer does nothing for 7 days, the success port fires and cancellation proceeds. If they contact support and the delay is cancelled externally, the cancelled port fires and the subscription is restored. The waiting port fires immediately to record the cooling-off start time in the CRM.