Wait

The Wait node pauses workflow execution for a specified duration. Use it for delayed follow-ups, scheduled reminders, rate limiting, or any scenario where timing matters.

Overview

Configuration

Amount

The numeric duration value:

• Minimum: 1
• Maximum: Depends on unit (practical limits apply)

Unit Options

How It Works

Input arrives
      │
      ▼
[Wait: 2 days]
      │
   (pause)
      │
 (2 days later)
      │
      ▼
Output (same data)

The Wait node:

1. Receives input data
2. Pauses execution for the specified duration
3. Resumes and outputs the same data unchanged
4. Downstream nodes continue processing

Input Schema

Accepts any data from upstream. Data passes through unchanged.

Output Schema

Same as input—data is preserved during the wait:

// Input
{
  "meeting": { "title": "Q1 Review" },
  "summary": "Discussed quarterly goals..."
}

// Output (after wait) - identical
{
  "meeting": { "title": "Q1 Review" },
  "summary": "Discussed quarterly goals..."
}

Examples

Basic Example: Delayed Follow-up

Send a follow-up email 2 days after a meeting.

Workflow:

[Event Trigger: MEETING_ENDED]
            │
            ▼
[Load Meeting]
            │
            ▼
[AI: Generate follow-up]
            │
            ▼
[Wait: 2 days]
            │
            ▼
[Email Send]

Configuration:

• Amount: 2
• Unit: days

Example: Multi-Touch Sequence

Create a sequence of follow-ups at different intervals.

Workflow:

[Meeting Ended]
      │
      ▼
[Email: Same-day thanks]
      │
      ▼
[Wait: 3 days]
      │
      ▼
[Email: Follow-up check-in]
      │
      ▼
[Wait: 1 week]
      │
      ▼
[Email: Final follow-up]

Example: Rate Limiting

Add delays between API calls to avoid rate limits.

Workflow:

[Select Many: items]
         │
         ▼
[API Call]
         │
         ▼
[Wait: 1 second]  ← Prevents rapid-fire calls
         │
         ▼
[Next Step]

Configuration:

• Amount: 1
• Unit: seconds

Example: Business Hours Consideration

Wait until a reasonable time to send (combine with scheduling).

Workflow:

[Meeting Ended at 11 PM]
            │
            ▼
[AI: Prepare summary]
            │
            ▼
[Wait: 10 hours]  ← Pushes to next morning
            │
            ▼
[Email Send]

Example: Conditional Wait

Different wait times based on conditions.

Workflow:

[AI: Classify urgency]
         │
         ▼
[If: urgent?]
    ├── Yes ──▶ [Wait: 1 hour] ──▶ [Follow-up]
    └── No ───▶ [Wait: 3 days] ──▶ [Follow-up]

Example: Quarterly Review Reminder

Set a long-term reminder.

Workflow:

[Deal Closed Won]
        │
        ▼
[Wait: 3 months]
        │
        ▼
[Create Task: "Quarterly review call"]

Configuration:

• Amount: 3
• Unit: months

Best Practices

1. Consider Business Context

Choose wait durations that make sense:

• Same-day: Thanks you emails
• 2-3 days: Initial follow-ups
• 1 week: Check-ins
• Longer: Nurture sequences

2. Don't Over-Wait

Very long waits increase risk:

• Context may change
• Data may be stale
• Better to use scheduled triggers for long-term

3. Handle Stale Data

After waiting, data may be outdated:

• Reload current state if needed
• Check if conditions still apply
• Handle cancellation scenarios

4. Test Wait Durations

For testing:

• Use short waits (seconds/minutes) during initial testing
• Don't release with long waits until verified with short durations first
• Release a version with the MANUAL trigger and short wait times to verify behavior before switching to production settings

5. Document Wait Purpose

Make the wait's purpose clear in workflow design:

[Wait: 2 days (Allow time for prospect to review proposal)]

Common Issues

Wait seems to hang

Symptom: Workflow appears stuck at Wait node

Reality: This is expected behavior—it's waiting!

Solutions:

1. Check execution logs for wait end time
2. For testing, use shorter durations
3. Be patient for production waits

Stale data after wait

Symptom: Data after wait doesn't reflect current state

Cause: Original data is preserved, not refreshed

Solution: Add a Load node after Wait to get fresh data:

[Wait: 3 days] ──▶ [Load Meeting] ──▶ [Use fresh data]

Wrong timezone calculations

Symptom: Wait ends at unexpected time

Cause: Wait is duration-based, not time-based

Solution: For specific times, use Scheduled Trigger instead, or calculate duration based on desired end time.

Execution failure during wait

Symptom: Downstream never executes after wait

Cause: System restart or execution cleanup

Solution: The execution engine persists wait state. If issues persist, check execution logs.

Related Nodes

• Scheduled Trigger - For specific times instead of durations
• If - Conditional routing with different waits
• Load Meeting - Refresh data after wait

Technical Details

Implementation

Wait nodes use scheduled message enqueueing:

1. Execution reaches Wait node
2. Continuation is scheduled for future time
3. System picks up continuation at scheduled time
4. Execution resumes

State Persistence

During the wait:

• Execution state is persisted to database
• System restarts don't lose the wait
• Data is preserved exactly as received

Duration Calculation

Note: Months and years use approximate values for simplicity.

Execution Status

During wait, execution status remains "running" with the Wait node in progress.

Practical Limits

While you can configure long waits:

• Very long waits (months/years) may span system changes
• Consider scheduled triggers for recurring long-term tasks
• Short-to-medium waits (minutes to weeks) are most reliable