Agentic Workflow Delays and Time-Based Behavior
Audience: Administrators, Developers, Solution Architects
Purpose: Understand how delay steps function within the Agentic Workflow execution model, how time-based behavior is governed by business calendars and timezones, and what to account for when designing Agentic Workflows where timing is critical.
Overview
Delay steps introduce intentional pauses into Agentic Workflow 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 Agentic Workflows.
Agentic Workflows 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.
Why Delays Matter
Agentic Workflow actions execute sequentially and immediately by default. Without delays, every action in an Agentic Workflow fires as fast as the execution engine processes it, which is appropriate for many 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 Condition or checking a goal gives the Record time to reach the expected state; for example, waiting 24 hours before checking whether a Contact has responded.
Coordination with external processes: Some 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 Record too quickly after a triggering event can produce incorrect or incomplete results, particularly when related Record 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
Kizen supports two delay types: Static and Agentic Workflow Variable. The right choice depends on whether the wait period is fixed or tied to a date on the Record.
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.
Note: The delay timer starts when a Record reaches the delay step, not when the Agentic Workflow is triggered. In time-sensitive sequences, account for any processing time between trigger and delay.
Agentic Workflow Variable
An Agentic Workflow 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 Condition or event to occur on the execution's Record. Used together, they create a bounded wait: execution holds for a set period, and if a goal Condition is met before the delay expires, execution can advance early.
This pattern is common in drip campaigns where execution should respond to a 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 Record. In practice:
The execution appears in the Record's history as active for the full duration of the delay
It counts against any relevant execution limits while active
Actions taken on the Record during the delay can affect the execution. Archiving the Record will cancel it.
Agentic Workflows 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 Agentic Workflows 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 Agentic Workflow 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 Agentic Workflows, including delay resolution, scheduled trigger evaluation, and On or Around Date trigger behavior.
User timezone: Agentic Workflows run in an Agentic Workflow context, not a user context. User timezone does not govern Agentic Workflow 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 Agentic Workflow, but goals add a conditional dimension. A goal is scoped to the running execution and waits for a specific event or Condition on the Record, 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.
Last updated
Was this helpful?