> ## Documentation Index
> Fetch the complete documentation index at: https://learn.workflow.dog/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect Data

> Pass values between actions, configure fixed inputs, and expose the exact outputs you need.

Every connection in a workflow carries a value from an output on one node to
an input on another. The connection also creates an execution dependency: the
receiving action waits for the connected output before it runs.

## Static and dynamic inputs

Most inputs can receive their value in one of two ways:

<Tabs>
  <Tab title="Static">
    Enter a fixed value directly in the node's configuration. The same value is
    used on every run.

    Static inputs are a good fit for constants such as a model name, status,
    email subject, or other fixed configuration.
  </Tab>

  <Tab title="Dynamic">
    Connect an output from another node. The input receives the value produced
    during the current run.

    Dynamic inputs are required when a value comes from trigger data, an API
    response, a calculation, or any other action.
  </Tab>
</Tabs>

For an input that supports both modes, use **Configure dynamically** to switch
between them. Starting a connection to the input switches it to dynamic mode
automatically.

<Warning>
  Switching a connected input back to static configuration removes the
  connection to that input. Confirm the fixed value before changing modes.
</Warning>

Some settings are configuration-only and cannot be connected. They define the
shape or behavior of the node itself rather than data for a run.

## Match data types

Handles indicate the kind of value they accept, such as String, Number,
Boolean, List, Object, File, or a package-specific type. Connect compatible
types whenever possible.

An **Any** handle accepts any value, but the receiving action still decides
what values are meaningful. For example, [Parse JSON](/reference/actions/core/json-parse)
accepts a String containing JSON; connecting an arbitrary value does not make
it valid JSON.

Use conversion actions when the types differ:

* [To Number](/reference/actions/core/to-number) converts compatible values to
  a number.
* [To Boolean](/reference/actions/core/to-boolean) converts a value using
  boolean semantics.
* [Convert to JSON](/reference/actions/core/json-stringify) serializes a value
  as JSON text.
* [Parse JSON](/reference/actions/core/json-parse) turns JSON text back into a
  structured value.

<Tip>
  Preserve a value's native type for as long as possible. Convert objects or
  lists to text only when the next system actually requires text.
</Tip>

## Select part of an object

Object-producing actions can expose the whole object and selected properties.
When the node shows **Select Property**, add only the properties downstream
actions need. Each selected property becomes its own output handle.

You can also select a nested property from a completed run:

<Steps>
  <Step title="Run the workflow">
    A real output gives the editor the object's current shape.
  </Step>

  <Step title="Open the output value">
    Choose the property path from the run result.
  </Step>

  <Step title="Connect the selected value">
    The editor exposes that path as a connectable output. For outputs that do
    not support property handles directly, it can route the value through [Get
    Properties](/reference/actions/objects/get-properties).
  </Step>
</Steps>

Property selection keeps the rest of the workflow readable and avoids passing
a large object into an action that needs only one field.

<Note>
  A property can be absent in a later run even if it appeared in the run you
  inspected. Validate optional or external data before relying on it.
</Note>

## Repeatable inputs

Some nodes accept a variable number of values. Examples include items in
[Create List](/reference/actions/arrays/build), values in
[Fallback](/reference/actions/control/coalesce), and properties in
[Create Object](/reference/actions/objects/build).

Repeatable inputs support two common layouts:

* **Individual items** — Add, remove, and reorder entries, then configure or
  connect each one separately.
* **Entire list at once** — Connect one List whose items become the repeatable
  input.

Use individual items when the workflow has a small, known set of sources. Use
an entire list when the number of values comes from runtime data.

For key/value inputs, each repeatable row contributes a property to an object.
Keys should be unique; a later duplicate key replaces the earlier property
when the object is assembled.

## Repeatable outputs

Some actions can expose either a complete collection or selected entries. In
individual mode, each configured output corresponds to one position or
property in the result. In whole-list mode, one output carries the collection.

Choose based on what happens next:

* Connect the whole list to actions such as
  [Loop Workflow](/reference/actions/core/loop-workflow),
  [Join Lists](/reference/actions/arrays/join), or
  [Filter With Workflow](/reference/actions/arrays/filter-with-workflow).
* Select individual items when later branches need separate values. For
  position-based access, [Get Items by Index](/reference/actions/arrays/get-items)
  makes the intended indexes explicit.

## Design reliable connections

Treat a node's outputs as a small contract with its downstream consumers:

1. Connect the narrowest useful value.
2. Keep structured values structured.
3. Convert types at a clear boundary.
4. Account for `null`, missing properties, and empty lists.
5. Run the workflow once and inspect the actual output before building a long
   downstream chain.

For data that may be missing, [Fallback](/reference/actions/control/coalesce)
can choose the first non-null or truthy candidate. For a hard requirement,
[Throw Error](/reference/actions/core/throw-error) can stop the run with a
clear message.