The three delay types, and what each is actually for
The event-based delay is the most under-used and the most powerful. It replaces the old pattern of branching every few steps to re-check whether something happened.
| Delay type | Use it when | The trap |
|---|---|---|
| Fixed amount of time | Pacing a nurture: wait 3 days between emails | A 3-day wait can land at 2am; it inherits the enrolment timestamp |
| Until a date or time | Keeping sends in business hours or on a launch date | Time zone: portal time vs contact time zone are different settings |
| Until an event or condition | Wait for a form submit, deal stage, or property change | No maximum wait means contacts sit in the workflow indefinitely |
Delays and re-enrolment: where double-sends come from
A contact sitting inside a five-day delay is still enrolled. If your re-enrolment trigger fires again, you can end up with the same contact in two positions in the same workflow, and both will complete their remaining actions.
Two habits prevent almost all of it: turn re-enrolment on deliberately rather than by default, and add a suppression check immediately after any delay longer than 24 hours.
- 01Decide whether re-enrolment is genuinely required. Most nurtures do not need it.
- 02After every delay over a day, add an if/then branch that re-checks the condition that justified the next action.
- 03Add global suppression — unsubscribed, customer, open deal, in another sequence — as an exclusion list rather than repeating the same filters in every workflow.
- 04Use goal criteria so contacts who convert exit rather than continue receiving nurture steps.
- 05Test with a real record, not a test contact created five minutes ago; timing bugs need realistic history.
Time zones and business hours
Two separate settings decide when a delayed action fires: the workflow's execution schedule and whether sends respect the contact's own time zone. If you have an international list and never touched either, you are emailing people overnight.
The reliable pattern is a scheduled delay to a business-hours window on weekdays, combined with contact-time-zone sending where it is available. It costs one extra step and removes an entire class of complaints.
Naming and documentation, because delays are invisible
You cannot see a delay from the workflow list. Six months later, nobody remembers that the 'welcome' workflow waits four days before step two, so they build a second workflow that overlaps it.
Put the timing in the workflow name and the description: the convention we use is [Object] | [Trigger] | [Purpose] | [Owner] | v1, with delay behaviour in the description field. Our free workflow naming generator produces these consistently.
A quarterly delay review
- List workflows containing delays longer than seven days and confirm each is still wanted.
- Find event-based delays with no maximum wait and set one.
- Check for contacts currently sitting in delays — a large stalled population usually means a broken condition.
- Confirm every long delay is followed by a suppression re-check.
- Archive workflows that have enrolled nobody in six months rather than leaving them on.
Common mistakes
- Using a fixed delay when you meant 'wait until Tuesday 9am'.
- Leaving event-based delays without a maximum wait, so contacts never exit.
- Turning on re-enrolment without a suppression re-check after the delay.
- Ignoring contact time zone on an international list.
- Hiding critical timing inside a workflow with a name like 'Nurture 2 FINAL'.