The Delay block pauses an Automation Studio flow for a set duration, or until a specific date and time, before it continues. This is essential for time-sensitive workflows such as follow-up emails or reminders. When a flow reaches a Delay block, everything after it is paused and only resumes once the defined delay period has passed.

How to configure a Delay block

You can configure a Delay block with either a duration, or a specific date and time. If you use a specific date and time, you can also set an offset to trigger the delay before, on, or after that point. For example, to send an email 24 hours after a trigger, you'd add a Delay block set to 24 hours, followed by an action block to send the email.

Points to remember

• A Delay block cannot be the last block in a path. At least one action block must follow it for the flow to actually execute.
• Multiple Delay blocks cannot be configured within the same path.
• If a record is updated again while a delay is running, the existing delay is overridden and the timer restarts from the latest update. For example, a ticket updated on Day 1 schedules an action for Day 4. If that same ticket is updated again on Day 2, the Day 4 schedule is cancelled and the action is rescheduled to Day 5.
• Delay execution isn't tied to any particular time zone. It runs based on the configured execution time.
• If a Delay block is deleted, every pending job it had scheduled is deleted with it, and the same applies if the whole rule is deleted.
• If a record with a pending scheduled action is moved to the Recycle Bin, that action won't run. If the record is restored before the scheduled time passes, the action will still run as originally scheduled.

Business scenarios

Sending a follow-up after resolution

A support team wants to check in with customers two days after their ticket is resolved, giving them a straightforward way to come back if the fix didn't actually work. The flow triggers on Ticket Updated with criteria that the Ticket Status changed to Closed, followed by a Delay block of 2 days, an If block confirming the status is still Closed, and an action that sends a short follow-up email asking whether the customer needs further help. The two-day delay gives the customer time to confirm the issue is genuinely resolved before the follow-up goes out.

Automated ticket follow-up and escalation

A support team wants a complete lifecycle flow: unassigned tickets should be escalated after 30 minutes, and tickets still open after 7 days should be escalated to management. The flow triggers on Ticket Created and forks into two paths. The first waits 30 minutes, checks whether the ticket is still unassigned, and if so assigns it to a support rep, raises the priority to High, and notifies that rep. The second waits 7 days, checks whether the ticket is still not closed, and if so notifies both the assignee and the support manager and updates the status to Escalated. The two delay periods act as independent checkpoints in the ticket's lifecycle, running in parallel from the moment the ticket is created, so both the early unassigned check and the longer-running escalation check happen automatically without anyone needing to track them manually.