Setting the file. One moment.
Subchapter 27.12
references/trigger-input-data-shapes.mdMarkdown2 KBView on GitHub
inputData shapeUsed by workflow_builder_verify_built_workflow and run_workflow. The pin-data adapter spreads or wraps based on trigger type —
passing the wrong shape gives null downstream values that look like an
expression bug.
Flat field map, e.g. {name: "Alice", email: "a@b.c"}. The production Form
Trigger emits each field directly on $json, so the builder’s $json.<field>
expressions are correct. Do NOT wrap in formFields — the adapter will
reject the call.
The body payload, e.g. {event: "signup", userId: "..."}. The adapter wraps it
under body, so downstream nodes reference $json.body.<field>.
A flat payload leaves query, headers and params empty. Those fields
resolve empty, and a simulated downstream node can still look green. So when
the workflow reads request fields ($json.query.*, $json.headers.* or
$json.params.*), pass the full envelope {body, query, headers, params}, e.g.
{body: {...}, query: {caller: "+1555..."}, headers: {"x-github-event": "issues"}, params: {}}.
{chatInput: "user message"}.
Omit inputData; the adapter emits synthetic timestamp fields.
Linear, GitHub, Slack, MCP, and similar triggers: pass inputData matching the
trigger’s expected payload shape from the node type definition.
Do not patch a workflow first when verify returns null downstream values.
Re-run verify with the corrected inputData shape. Only patch the workflow if
the expression is wrong against the production trigger output shape (consult
node descriptions), not the instanceAi pin data path.