Delay Workflow

Last updated: April 12, 2026

Last Updated: April 12, 2026

Customer-Facing Guide

What this action does

Delay Workflow pauses the workflow for a defined period before the next step runs. It is one of the most useful control steps for avoiding race conditions, spacing out messages, and giving other systems time to finish syncing contact data.

When delay is helpful

  • You need time for assignment, tags, custom variables, or CRM data to finish syncing before the next step.

  • You want space between messages or actions so the workflow does not fire everything immediately.

  • You need to wait before checking for a reply, evaluating a condition, or sending a reminder.

What delay does not fix

  • Delay does not fix the wrong trigger or broken enrollment criteria.

  • Delay does not make a missing field appear if that field is never being sent into Sendblue at all.

  • Delay does not solve line health or delivery issues when the real problem is outside workflow timing.

How to choose the right delay

  • Use the shortest delay that reliably allows the required data to arrive.

  • If the next step depends on CRM sync, tags, or owner assignment, test with the same real source you use in production.

  • If your reminders need human-readable timing, confirm how the workflow behaves relative to local timezone, appointment time, or webinar time in the source system.

Common use cases

  • Add a short delay after contact creation so owner assignment or custom variables are available.

  • Pause before a reminder message so the contact is not hit with back-to-back sends.

  • Wait before checking downstream conditions that would otherwise evaluate too early.

Common mistakes

  • Using a delay that is too short for the upstream system to finish syncing.

  • Relying on delay to paper over a trigger or segmentation problem that should be fixed directly.

  • Forgetting that a later message may now fire later in the day or outside the expected window.

  • Adding delay everywhere without confirming which specific step actually needs more time.

How to verify it worked

  1. Open execution logs and confirm the contact paused at the delay step before continuing.

  2. Check the timestamp of the next step to make sure it ran after the expected interval.

  3. If the next step still fails, review whether the root problem is data readiness, segmentation, or workflow design rather than raw timing.

A simple troubleshooting rule

If the contact never enrolled, investigate the trigger. If the contact enrolled but the next step ran too early or with incomplete data, investigate delay length and execution order. That split saves a lot of time.

Related guides