Wait Node - Synthreo Builder
Wait node for Builder - introduce a timed pause into an AI agent workflow, delaying execution by a specified duration before passing control to the next node.
Purpose
Section titled “Purpose”The Wait node delays workflow execution for a specified duration before passing control to the next node. It allows workflows to introduce deliberate pauses for throttling, synchronization, polling intervals, and timing alignment with external systems.
No data is modified during the wait. All input data is held and passed through unchanged once the delay completes.
Inputs
Section titled “Inputs”- Duration - A numeric value specifying how long to pause workflow execution.
- Unit - A dropdown specifying the scale of the duration value.
Outputs
Section titled “Outputs”Passes the input data unchanged to the next node after waiting the specified amount of time. No data is transformed or generated by this node. The sole effect is the delay introduced before the next node begins executing.
Parameters
Section titled “Parameters”| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| Duration | Number | Yes | (empty) | The numeric duration to wait. Must be a positive value. The meaning of this number depends on the selected Unit. |
| Unit | Dropdown | Yes | (empty) | The time scale for the duration. Options: Milliseconds, Seconds, Minutes. |
How It Works
Section titled “How It Works”When the workflow reaches the Wait node, execution pauses for the calculated duration (Duration multiplied by the scale of the selected Unit). Once the delay completes, execution resumes and data is forwarded to the next connected node. The wait is synchronous within the workflow - no other steps in the same workflow branch execute during the pause.
When to Use This Node
Section titled “When to Use This Node”- API rate limiting: When calling an external API that enforces a rate limit (e.g., a maximum number of requests per second or per minute), place a Wait node between API call nodes to stay within the allowed request rate.
- Polling intervals: When a workflow checks the status of an async operation (such as a file becoming available or a job completing), use a Wait node between check attempts to avoid hammering the external system with rapid repeated requests.
- Synchronization with external systems: When a downstream system requires time to process a previous step before the next step can proceed (such as a database write that needs to complete before a read), use a Wait node to introduce the necessary buffer.
- Timed triggers and scheduled delays: When a workflow step should only run after a specific elapsed time, such as sending a follow-up message a set number of minutes after an initial action.
Step-by-Step (Quick Start)
Section titled “Step-by-Step (Quick Start)”- Add the Wait node to your workflow from the node panel.
- Enter a positive numeric value in the Duration field.
- Select the appropriate time scale from the Unit dropdown (Milliseconds, Seconds, or Minutes).
- Connect the Wait node between the node that should execute before the pause and the node that should execute after.
- Run the workflow and verify that execution resumes after the specified duration.
- Save and deploy.
Example Usage
Section titled “Example Usage”API Rate Limit Management
Section titled “API Rate Limit Management”A workflow submits records to a third-party API that allows a maximum of one request per second. A Wait node is placed between each API call to enforce the rate limit.
Configuration:
Duration: 1Unit: Seconds
Result: Workflow execution pauses for one second between API requests, preventing rate limit errors.
Async Job Status Polling
Section titled “Async Job Status Polling”A workflow submits a report generation job to an external system and then polls for completion. A Wait node between each poll attempt prevents excessive requests while waiting for the job to finish.
Configuration:
Duration: 30Unit: Seconds
Result: The workflow waits 30 seconds between each status check, giving the external system time to process without being overwhelmed by rapid polling.
Delayed Follow-Up Action
Section titled “Delayed Follow-Up Action”A workflow sends an initial notification to a user and then waits two minutes before sending a follow-up confirmation.
Configuration:
Duration: 2Unit: Minutes
Result: The follow-up step executes exactly two minutes after the initial notification is sent.
Best Practices
Section titled “Best Practices”- Use short delays during development and testing: Long wait durations slow down your feedback loop when building and debugging a workflow. Set shorter durations during development and update to production values before deploying.
- Avoid unnecessary pauses: Only insert a Wait node where timing control is genuinely required. Adding Wait nodes as a precaution without a specific reason increases workflow execution time and can cause timeouts in time-sensitive scenarios.
- Combine with external checks: When polling an external system, use the Wait node before a status-check node rather than after, to ensure the external system has adequate time to process before the check is made.
- Document the reason for each wait: Use an Annotation node near each Wait node to explain why the delay is needed, what rate limit or timing constraint it is addressing, and what value was chosen. This helps future maintainers understand and adjust the configuration.
- Confirm unit selection: A common mistake is entering a duration in seconds while the Unit is set to Minutes, resulting in a much longer delay than intended. Always verify both the Duration value and the Unit setting together.
Troubleshooting
Section titled “Troubleshooting”Workflow times out during the wait
Section titled “Workflow times out during the wait”If the workflow has an execution timeout configured and the Wait duration exceeds it, the workflow will time out before the wait completes. Reduce the Wait duration or increase the workflow timeout limit if appropriate for your use case.
Wait appears to have no effect
Section titled “Wait appears to have no effect”Confirm that the Duration field contains a positive numeric value and that the Unit dropdown is set correctly. A Duration of 0 or a negative value may be treated as no delay or may produce an error.
Downstream node receives no data after the wait
Section titled “Downstream node receives no data after the wait”The Wait node passes all input data through unchanged. If the downstream node is not receiving data, check the connection between the Wait node and the next node on the canvas. Also confirm that no preceding node in the workflow produced an empty output.
Wait duration is much longer than expected
Section titled “Wait duration is much longer than expected”Verify that the Unit is not set to a larger scale than intended. For example, if you intended a 5-second wait but the Unit is set to Minutes, the workflow will pause for 5 minutes. Double-check both the value and the unit setting.
Test Cases
Section titled “Test Cases”- Given:
Duration = 500,Unit = Milliseconds- Expected: Workflow resumes after 0.5 seconds. - Given:
Duration = 5,Unit = Seconds- Expected: Workflow resumes after 5 seconds. - Given:
Duration = 1,Unit = Minutes- Expected: Workflow resumes after 60 seconds. - Given: Invalid or negative duration value - Expected: Error indicating invalid wait duration; workflow does not proceed.
Related Nodes
Section titled “Related Nodes”- Annotation - Use alongside this node to document the reason for each delay, especially for rate limiting or polling scenarios.
- Custom Script - Can be used before a Wait node to calculate a dynamic delay duration based on response data from an upstream API call.