post-build-flow

Source excerpt starting at line 1.

1# Per-trigger `inputData` shape2 3Used by `verify-built-workflow`, `executions(action="run")`, and checkpoint4verification. The pin-data adapter spreads or wraps based on trigger type —5passing the wrong shape gives null downstream values that look like an6expression bug.7 8## Form Trigger (`n8n-nodes-base.formTrigger`)9 10Flat field map, e.g. `{name: "Alice", email: "a@b.c"}`. The production Form11Trigger emits each field directly on `$json`, so the builder's `$json.<field>`12expressions are correct. **Do NOT wrap in `formFields`** — the adapter will13reject the call.14 15## Webhook (`n8n-nodes-base.webhook`)16 17The body payload, e.g. `{event: "signup", userId: "..."}`. The adapter wraps it18under `body`, so downstream nodes reference `$json.body.<field>`.19 20## Chat Trigger (`@n8n/n8n-nodes-langchain.chatTrigger`)21 22`{chatInput: "user message"}`.23 24## Schedule Trigger (`n8n-nodes-base.scheduleTrigger`)25 26Omit `inputData`; the adapter emits synthetic timestamp fields.27 28## Other event triggers29 30Linear, GitHub, Slack, MCP, and similar triggers: pass `inputData` matching the31trigger's expected payload shape from the node type definition.32 33## Debugging wrong null values34 35**Do not patch a workflow first when verify returns null downstream values.**36Re-run verify with the corrected `inputData` shape. Only patch the workflow if37the expression is wrong against the *production* trigger output shape (consult38node descriptions), not the `instanceAi` pin data path.39