Dynamiq
Workflows

Node Configuration

The node inspector explained tab by tab — Configuration, Output, and Error Handling — plus the special Input/Output node panels and retry semantics.

Selecting any node on the canvas opens the inspector on the right. Its header shows the node's title, a short description, and — for many node types — an info button linking to that node's reference docs. When you select an item nested inside a container (an agent's LLM or tool), a Go back link returns you to the parent node.

Every standard node has the same three tabs: CONFIGURATION, OUTPUT, and ERROR HANDLING. The Input and Output nodes are special-cased and show a fields editor instead (covered below).

The node inspector with the Configuration, Output, and Error Handling tabs across the top

CONFIGURATION tab

This tab holds everything that defines what the node does. Contents vary by node type, but the recurring elements are:

Name

Every node has a Name field. The name doubles as the node's reference in selectors — downstream nodes address this node's outputs as $.<name>.output.<key> — so renaming a node after you've mapped its outputs elsewhere breaks those mappings. Name your nodes early.

Connection

Nodes that call an external service have a connection selector. Each node type accepts specific Connection types — an OpenAI LLM takes an OpenAI connection, SQL Executor takes PostgreSQL/MySQL/Snowflake/Amazon Redshift, MCP Server takes MCP Streamable HTTP or SSE, and so on. Create connections under Connections first, then pick them here.

Node-specific settings

Whatever the node type needs: model and generation parameters for LLMs, Role & Instructions plus tools for the Agent (with advanced settings like Max loop under Advanced configuration), the query for SQL Executor, chunking parameters for Document Splitter, and so on.

Input fields (the mapping section)

The node's typed input fields appear here, one control per field. Each control shows the field label, its expected type in monospace (for example list[Document]), and an (optional) marker when the field isn't required. Fill a field with:

  • A variable — press / to open the picker of upstream outputs ("Type text or press '/' to add variables"). Picking one inserts a token backed by a selector like $.input.output.input. Only type-compatible outputs from upstream nodes are offered.
  • Literal text or a number — typed directly, where the field's type allows it. Fields with strict types (such as list[Document]) accept variables only ("Select a variable").

A field holds one or the other: with a token present, typing is disabled; with text present, the picker is blocked until you clear it. The full selector syntax is covered in Input transformers and Jinja, and the compatibility rules in How nodes connect.

An input field with the variable picker open, showing upstream nodes and their typed outputs

OUTPUT tab

A read-only reference: every output key the node produces, with its type.

The Output tab listing the node's output keys and their data types

Use it two ways:

  • When mapping downstream, these keys are exactly what you reference: $.<name>.output.<key>.
  • When the variable picker won't offer this node for some field, compare types here against the target field's type — the mismatch is your answer.

For example, an Agent lists content (string) and files (list[file]); a web search tool lists a content dict plus drill-down keys like content.result and content.sources_with_url.

ERROR HANDLING tab

Controls what happens when the node fails, with retries, backoff, and a timeout. All fields are optional.

The Error Handling tab with Behavior, retry, and timeout settings
BehaviorRaise | Return
The behavior when an error occurs. Default: Raise.
Intervalnumber
Seconds before the first retry attempt. Must be greater than 0. Default: 1.
Max attemptsnumber
Maximum number of retry attempts. Must be 0 or greater. Default: 0 (no retries).
Backoff ratenumber
Multiplier applied to the retry interval on each attempt. Must be ≥ 1. Default: 1 (constant interval).
Timeout in secondsnumber
Fail the node if it runs longer than this. Must be greater than 0. Default: none.

Raise vs. Return

  • Raise (default) — a failure is fatal for the path: nodes that depend on this one see the failed dependency and fail or are skipped in turn. The run surfaces the error.
  • Return — the error becomes the node's result. Execution continues, and downstream nodes run with that failure result available — useful when a later node (a Choice branch, a fallback agent) should handle the error instead of aborting the run.

How retries are timed

A node attempts execution Max attempts + 1 times in total. Between attempts it waits Interval × Backoff rate^attempt seconds — so with Interval 2 and Backoff rate 3, the waits are 2s, 6s, 18s, … The timeout applies per attempt; a timed-out attempt counts as a failure and is retried like any other.

If a node also has an input-streaming timeout configured, it must be smaller than Timeout in seconds — the platform validates this so the streaming timeout can fire before the general execution timeout.

For workflow-level patterns (fallback branches, guarding agents with validators), see Error handling.

The Input and Output node panels

Selecting the Input or Output node opens a fields editor instead of the three tabs.

Input node fields

Each row is a field name plus a type: Any, String, Number, Boolean, List, Dictionary, Files, or File. These fields define the request schema — what callers send and what the Test panel's Request form asks for. Add field appends a row; the × removes a field.

The Input node panel with field rows, each with a name and a type selector

Output node fields

Each row is a field name, a value control (the same variable picker as any input mapping — choose which upstream output fills this response field), and a Required checkbox. Map every required field; an unmapped output is why a workflow "runs fine but returns nothing".

The Output node panel with each field's value mapped to an upstream output and a Required checkbox

Validation and errors

The editor validates on Test and Save:

  • Nodes with problems are outlined in red on the canvas, and the save panel blocks with "Your workflow has errors. You need to fix them before saving."
  • Server-side validation errors from a save attempt appear in a red banner at the top of the offending node's inspector, naming the invalid fields.

Next steps

On this page