Connectors

Sleep Connector

Pause workflow execution for a fixed number of milliseconds, clamped to a 5-minute ceiling, before continuing to the next step.

On this page

What this connector is for Sleep Configuring it Reading the response Example Step Name Step Reference

What this connector is for

Pauses the workflow for a fixed number of milliseconds before moving on to the next step. Use it to wait briefly for an upstream system to reach eventual consistency after a write, or to throttle the pace of successive calls to a rate-limited API. No connection is needed — like For Loop and Conditional Branch, this is a platform-internal control-flow step, not a call to anything external.

The delay is a fixed wall-clock wait (setTimeout) — it isn't computed from any external signal (e.g. a Retry-After header) and doesn't poll for a condition. To wait for a condition instead of a fixed duration, use Do While with a short delay inside its body.

Sleep

Configuring it

Milliseconds (milliseconds) — required, default 1000. How long to pause. Must be 0 or greater; values above the connector's hard ceiling of 300000ms (5 minutes) are silently clamped down to that ceiling rather than rejected, so a workflow can't tie up a live request/response cycle (or a batch job's own execution timeout) indefinitely — the same reasoning behind Code Connector's own execution timeout cap.

Reading the response

{{<stepReference>.response.data.slept}} — always true.
{{<stepReference>.response.data.milliseconds}} — the actual delay applied, after clamping — read this rather than echoing back your configured value if you need to confirm what really happened.
{{<stepReference>.response.data.startedAt}} / {{<stepReference>.response.data.completedAt}} — ISO timestamps bracketing the pause.

For example, a step named "Wait For Consistency" (reference waitForConsistency) — use {{waitForConsistency.response.data.milliseconds}} to confirm how long it actually paused.

Example

Milliseconds: 2000

Pauses for 2 seconds — useful for throttling between successive calls to a rate-limited API.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

Must be at least 2 characters, and 50 characters or fewer.
Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
Can't be empty.

Tips

Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
Object values are automatically JSON-stringified when interpolated into a string field.