Connection Tags

Connection tags are visual representations of the data available from connected blocks. They provide an easy way to reference outputs from previous blocks in your workflow.

What Are Connection Tags?

Connection tags are interactive elements that appear when blocks are connected. They represent the data that can flow from one block to another and allow you to:

• Visualize available data from source blocks
• Reference specific data fields in destination blocks
• Create dynamic data flows between blocks

Using Connection Tags

There are two primary ways to use connection tags in your workflows:

Tag Syntax

Connection tags use a simple syntax to reference data:

<blockname.path.to.data>

Where:

• blockname is the source block's name, lowercased with spaces removed. A block named "Customer Lookup" is read as <customerlookup.…>. The block's ID never resolves, and renaming a block updates the tags that point at it, including a Loop's collection and while condition.
• path.to.data is the path to the specific data field. Read an array element by its position, written either [0] or .0: <api2.data.users[0].name> and <api2.data.users.0.name> are the same reference.

For example:

• <agent1.content> - References the content field from a block named "Agent 1"
• <api2.data.users[0].name> - References the name of the first user in the users array from the data field of a block named "API 2"
• <start.customerName> - References the customerName field of the workflow's trigger payload; start is always available

A tag only resolves when the block it names runs before the block that reads it. The editor highlights a tag only when it can resolve; a tag that cannot is kept as literal text in text fields — <agent1.contnet> sends the text <agent1.contnet> — and becomes undefined in Function code and condition expressions.

A workflow with a tag that cannot resolve still saves: the save reports it as a warning. It does not deploy: deploying or promoting it is refused with workflow_reference_unresolvable (HTTP 422), and the refusal names each tag and the block it is in. Rename the tag or the block so they match, then deploy again. A tag on variable that names a declared workflow variable is a warning only.

Dynamic Tag References

Connection tags are evaluated at runtime, which means:

1. They always reference the most current data
2. They can be used in expressions and combined with static text
3. They can be nested within other data structures

Examples

// Reference in text
"The user's name is <userBlock.name>"

// Reference in JSON
{
  "userName": "<userBlock.name>",
  "orderTotal": <apiBlock.data.total>
}

// Reference in code: no quotes around the tag, string values are inserted as quoted literals
const greeting = "Hello, " + <userBlock.name> + "!";
const total = <apiBlock.data.total> * 1.1; // Add 10% tax

In a Function block's code and in condition expressions, write the tag on its own rather than inside a quoted string: "Hello, <userBlock.name>!" would become "Hello, "Ada"!", which is not valid code.

In a JSON field, such as a Response block's data, an Agent's response format, a table write's rows or a process instance's context, a tag is inserted according to where it stands:

• Inside a quoted string, as in "userName": "<userBlock.name>", the tag is replaced by the value's text, escaped. A double quote, a backslash or a line break in the value stays inside the string, and a value cannot add a key.
• On its own as a value, as in "orderTotal": <apiBlock.data.total>, the tag is inserted as JSON. Objects, arrays, numbers and booleans are inserted as they are. Text that is itself one JSON value is inserted as that value; any other text becomes a JSON string.

Two cases keep plain text substitution. A field that holds a single tag and nothing else, such as <agent1.content>, receives the value's own text. A field whose text is not JSON is also left to plain substitution.