younifyd
Menu

Connectors

Break Loop Connector

Immediately stop the nearest enclosing For Loop (For Each or Do While) — combine with a Conditional Branch to break only sometimes.

On this page

What this connector is for

Immediately stops the nearest enclosing For Loop (either For Each or Do While) the moment it runs — skipping any remaining iterations of that loop, but leaving a parent loop it might be nested inside completely unaffected. It takes no configuration and always "fails" in isolation by design — see below for what that actually means for the loop.

This connector has no condition input of its own. To break only sometimes, nest this step inside an If branch — e.g. "If {{runtimeVariables.isPending}} equals false → Break Loop" — rather than looking for a condition field here.

Break Loop

Configuring it

No configurable fields — this action's input schema is empty. Placement (which loop it's nested inside, and whether that placement is itself behind an If branch) is the entire configuration.

Reading the response

This action never actually returns a result — it always signals the enclosing loop by throwing. There's nothing to read via {{<stepReference>...}}. What you can observe instead, from the loop step itself once it stops:

  • A For Each loop's own {{<forLoopReference>.response.data.brokenEarly}} is true when a Break Loop step is what stopped it (as opposed to hitting the execution deadline).
  • A Do While loop's own {{<forLoopReference>.response.data.reason}} is "break" (and .brokenEarly is true) for the same reason.

If a Break Loop step somehow runs outside any For Loop, there's no enclosing loop to catch the signal — it propagates as an ordinary step failure and fails the workflow (or whichever ancestor step has Continue On Error enabled), rather than doing nothing.

Example

If {{runtimeVariables.isPending}} equals false:
  → Break Loop

Placed inside a For Loop's body, nested inside a Conditional Branch that checks the exit condition.

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.