Delay for Flows allows to pause the flow before continuing, enabling more controlled and predictable automation sequences.
Configuring Delay for Flows Action
In your Workflow, select the Built-in tool "Delay" as an action.
Choose the Wait Type as Event and based on your needs, there are 3 options to choose from:
Wait for Fixed Duration
What it does: This feature allows your flow to pause execution for a precise, set amount of time you define, selectable in seconds, minutes, hours or days.. It is used when you need a predictable delay before the next action, such as allowing an external system to process data, implementing a cool-down period, or adhering to rate limits.
Example: Wait for Fixed Duration
Imagine you send a new customer a welcome email, but you want to give them 24 hours to read it before sending a follow-up offer.
Trigger - Incoming email or catch hook
Flow Step : Send Welcome Email.
Flow Step (Wait for fixed duration): The flow pauses 24 hours
Flows Step : Send Detailed information email
How to Set Up the Action:
In your workflow, select the Delay action.
Wait Type: Wait for Fixed Duration
Duration: 24
Time Unit: Hours
The Result:
The flow will stop for exactly 24 hours from the moment it reaches this step. After the time has elapsed, the flow will automatically resume to send the follow-up offer.
Wait Until Timestamp
What it does: This feature pauses your flow until a specific, future date and time is reached. It is used for precise scheduling, ensuring a process aligns with a calendar event, a business deadline, or a pre-defined maintenance window, Ideal for scheduling follow-ups, coordinating time-based events or resuming processes at precise moments.
Example:
Imagine you've prepared a major system update that must go live exactly at midnight on the upcoming Friday, March 6th, 2026.
Trigger event - I.e a Webhook sent from an application or an incoming email
Flow Step: Prepare Update Files.
Flow Step (Wait until timestamp): The flow pauses. until midnight
Flow Step: Process or send data
How to Set Up the Action:
In your workflow, select the Delay action.
Wait Type: Wait Until Timestamp
Timestamp: 2026-03-06T00:00:00Z (The exact time of the scheduled launch)
The Result:
The flow will wait, regardless of how much time passes, until the clock hits 2026-03-06 at midnight (UTC ISO 8601 timestamp e.g., 2024-12-31T23:59:59Z)). It will then immediately resume to execute the system update.
Wait In Queue
What it does: This feature provides a crucial mechanism to manage concurrent executions that attempt to process the same data group. It acts as a distributed lock, pausing the current flow's execution if another flow is already active on the defined data group, thereby preventing race conditions, data corruption, or conflicting updates on shared resources.
How to Set Up the Action:
In your workflow, select the Wait action and configure it for Concurrent Execution Management (Data Group Lock).
Wait Type: Concurrent Execution Management (Wait in Queue)
Lock Key: Define an expression based on flow data (e.g. $.product_id, $.customer_id, $.invoice_number) that identifies the shared resource or data group.
Wait Behavior: Choose one of the following options:
Wait until the previous execution succeeds
Wait until the previous execution completes (succeeds or fails)
Example: for Wait Behavior: Wait until the previous execution succeeds
Imagine two separate flows, Flow A and Flow B, are triggered almost simultaneously to update the inventory level for the same Product ID: P-472. Flow A starts execution, acquires the lock on P-472, and proceeds to update inventory. Flow B starts execution, reaches the Wait in Queue step, finds the lock held by Flow A, and Pauses.
The Result:
Flow B automatically pauses. It will only wake up and proceed once Flow A finishes successfully (and the lock is released). If Flow A fails due to an error, Flow B will remain paused and continue waiting — it will not proceed until the previous execution succeeds. This ensures Flow B only ever works with data from a successful prior outcome, guaranteeing that subsequent operations build on a reliable foundation.
Example: for Wait Behavior: Wait until the previous execution completes (succeeds or fails
Using the same scenario: two flows (Flow A and Flow B) are triggered to update the inventory for Product ID: P-472. Flow A starts execution, acquires the lock on P-472, and proceeds to update inventory. Flow B starts execution, reaches the Wait in Queue step, finds the lock held by Flow A, and Pauses.
The Result:
Flow B automatically pauses. As soon as Flow A finishes—regardless of whether it succeeded or failed—Flow B immediately wakes up and attempts to acquire the lock to proceed with its update. This ensures Flow B always gets its turn to run, allowing it to handle potential recovery or subsequent processing based on the outcome of Flow A.