# Agentic Workflow Delays and Time-Based Behavior {% hint style="success" %} **Audience:** Administrators, Developers, Solution Architects **Purpose:** Understand how delay steps function within the space.vars.automation execution model, how time-based behavior is governed by business calendars and timezones, and what to account for when designing space.vars.automations where timing is critical. {% endhint %} ## Overview Delay steps introduce intentional pauses into space.vars.automation execution. How long an execution waits is governed by configured delay logic, business calendar settings, and the platform's timezone model. Incorrect assumptions in any of these areas are among the most common causes of unexpected behavior in production space.vars.automations. space.vars.automations are always asynchronous. When a delay expires, the execution is re-queued for processing rather than resuming instantaneously. A brief additional wait after the delay period ends is normal and consistent with the async queue behavior. See more details with [Agentic Workflow Execution and Process Model](/docs/concepts/agentic-workflows/agentic-workflow-execution-and-process-model.md). *** ## Why Delays Matter space.vars.automation actions execute sequentially and immediately by default. Without delays, every action in an space.vars.automation fires as fast as the execution engine processes it, which is appropriate for many space.vars.workflows, but not all.

Delays give you control over when actions happen, not just whether they happen. This matters in several scenarios: * **Drip campaigns and nurture sequences:** Spacing communications over days or weeks requires execution to pause between steps. Without delays, all messages in a sequence would send within seconds of each other. * **Conditional timing:** Waiting a defined period before evaluating a space.vars.condition\_step or checking a goal gives the space.vars.entity time to reach the expected state; for example, waiting 24 hours before checking whether a space.vars.contact has responded. * **Coordination with external processes:** Some space.vars.workflows depend on events or actions that take time outside the platform. Delays create the buffer needed to account for that time. * **Avoiding unintended side effects:** Acting on a space.vars.entity too quickly after a triggering event can produce incorrect or incomplete results, particularly when related space.vars.entity or field values are still being updated by other processes. Understanding how the platform measures and resolves delay time, including business calendar observance and timezone handling, is what separates a delay that behaves as intended from one that silently waits longer or shorter than expected. *** ## Delay Types space.vars.Kizen\_company\_name supports two delay types: Static and space.vars.automation Variable. The right choice depends on whether the wait period is fixed or tied to a date on the space.vars.entity. ### Static A static delay pauses execution for a fixed amount of time. The supported timeframes are minutes, hours, and days. The delay is measured from the moment the delay step is reached, not from when the trigger fired or the execution was created. {% hint style="warning" %} **Note**: The delay timer starts when a space.vars.entity reaches the delay step, not when the space.vars.automation is triggered. In time-sensitive sequences, account for any processing time between trigger and delay. {% endhint %} ### Agentic Workflow Variable An space.vars.automation variable delay pauses execution for a fixed amount of time using a number variable. The supported timeframes are minutes, hours, and days. The delay is measured from the moment the delay step is reached, not from when the trigger fired or the execution was created. #### Delays and Goals A delay waits for a fixed period of time. A goal waits for a specific space.vars.condition\_step or event to occur on the execution's space.vars.entity. Used together, they create a bounded wait: execution holds for a set period, and if a goal space.vars.condition\_step is met before the delay expires, execution can advance early. This pattern is common in drip campaigns where execution should respond to a space.vars.contact action before deciding what to do next. See Goals **(Topic Coming Soon)** for full detail on goal behavior, completion logic, and timeout handling. #### Active State During a Delay While a delay is in progress, the execution is in an active paused state. It has not completed and remains associated with the space.vars.entity. In practice: * The execution appears in the space.vars.entity's history as active for the full duration of the delay * It counts against any relevant execution limits while active * Actions taken on the space.vars.entity during the delay can affect the execution. Archiving the space.vars.entity will cancel it. space.vars.automations with delays of several days or weeks should be designed with long-lived executions in mind, particularly in high-volume environments. ### Business Calendars & Timezones Time-based behavior in space.vars.automations is affected by two platform-level settings: business calendar configuration and timezone. Both influence when delays resolve and how execution timestamps are interpreted. #### Skip Non-Business Days Each delay step includes a **Skip Non-Business Days** setting that controls whether non-working days count toward the delay period. By default, this is set to **Inherit from Agentic Workflow**, meaning the step follows the business calendar observance setting configured at the space.vars.automation level. A one-day delay with non-business days skipped waits one business day, not one calendar day. This distinction matters most when delays span weekends, holidays, or other non-working periods. #### Timezones **Business timezone:** The business's configured timezone is the primary reference for all time-based logic in space.vars.automations, including delay resolution, scheduled trigger evaluation, and On or Around Date trigger behavior. **User timezone:** space.vars.automations run in an space.vars.automation context, not a user context. User timezone does not govern space.vars.automation behavior, and user-relative filters such as "owner is me" are ignored during execution. Business timezone takes precedence for all evaluation purposes. **UTC storage:** All datetime values are stored in UTC. Displayed times reflect the applicable timezone conversion, not the raw UTC value. Keep this in mind when reading execution timestamps or configuring date-based delays. **DST handling:** When daylight saving time transitions occur, a time configured in one UTC offset may appear to shift when viewed after the transition. *** ## What's Next Delays and goals both introduce waiting behavior into an space.vars.automation, but goals add a conditional dimension. A goal is scoped to the running execution and waits for a specific event or space.vars.condition\_step on the space.vars.entity, rather than a fixed period of time. The Agentic Workflow Goals **(Topic Coming Soon)** topic covers goal evaluation, completion and timeout behavior, and when to use a goal alongside or instead of a delay, particularly relevant for drip campaigns and follow-up sequences.