Skip to main content
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:
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.
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.
Switching a connected input back to static configuration removes the connection to that input. Confirm the fixed value before changing modes.
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 accepts a String containing JSON; connecting an arbitrary value does not make it valid JSON. Use conversion actions when the types differ:
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.

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:
1

Run the workflow

A real output gives the editor the object’s current shape.
2

Open the output value

Choose the property path from the run result.
3

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.
Property selection keeps the rest of the workflow readable and avoids passing a large object into an action that needs only one field.
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.

Repeatable inputs

Some nodes accept a variable number of values. Examples include items in Create List, values in Fallback, and properties in Create Object. 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:

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 can choose the first non-null or truthy candidate. For a hard requirement, Throw Error can stop the run with a clear message.