node cookbook
n8n Set Node: Clean Payloads Before APIs, Sheets, and Databases
Use the Set node, also known as Edit Fields, to create, rename, keep, remove, or normalize fields before sending data to later nodes.
Match your incident first
Start with the symptom you can prove
Referenced node did not execute
First check: Open the failed execution and inspect which branch produced the current item.
Wrong fix to avoid: Do not add dummy Set nodes just to silence the error without fixing data flow.
Verify: The expression handles both branch outcomes or references only nodes guaranteed to run.
Field is missing on some items
First check: Pin or inspect multiple real items, not only the first successful item.
Wrong fix to avoid: Do not hardcode array indexes before checking all item shapes.
Verify: The expression uses safe access/defaults and succeeds for empty, partial, and normal items.
Expression works in manual test but fails in production
First check: Compare pinned test data with a recent production execution payload.
Wrong fix to avoid: Do not rely on pinned data as proof of production behavior.
Verify: A fresh production execution with live data passes the same expression.
- Use when
- n8n workflows, data shaping
- First check
- Inspect the runtime item shape from the previous node, not just the expression template.
- Time to check
- 5-10 minutes
- Next step
- Match the symptom, then run the verification checks.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Use the Set node, also known as Edit Fields, to create, rename, keep, remove, or normalize fields before sending data to later nodes.
Does this match your symptom?
Expression or payload shape is failing
A node receives unexpected data, invalid JSON, missing fields, or an expression works only on one branch.
First check: Inspect the runtime item shape from the previous node, not just the expression template.
Problem Pattern
The user has messy incoming data and needs a predictable output shape before sending it to an API, sheet, database, or app node.
Version awareness
Last reviewed 2026-05-21
Key Facts
- Node role
- Edit the fields on workflow items.
- Best fit
- Data cleanup, field mapping, shaping API payloads, and simplifying downstream nodes.
- Common output
- A predictable object shape for app, HTTP, or database nodes.
- Common companion nodes
- IF, Merge, HTTP Request, Code, Webhook, and app nodes.
Production Diagnostic Matrix
Turn checks into a brief| Exact symptom or log | Likely cause | First check | Wrong fix to avoid | Verification |
|---|---|---|---|---|
| Referenced node did not execute | Expression reads from a node on a branch that did not run for this item. | Open the failed execution and inspect which branch produced the current item. | Do not add dummy Set nodes just to silence the error without fixing data flow. | The expression handles both branch outcomes or references only nodes guaranteed to run. |
| Field is missing on some items | Input items have inconsistent shape, optional provider fields, or previous node output changed. | Pin or inspect multiple real items, not only the first successful item. | Do not hardcode array indexes before checking all item shapes. | The expression uses safe access/defaults and succeeds for empty, partial, and normal items. |
| Expression works in manual test but fails in production | Manual pinned data differs from live payload, timezone, credentials, or branch timing. | Compare pinned test data with a recent production execution payload. | Do not rely on pinned data as proof of production behavior. | A fresh production execution with live data passes the same expression. |
| Invalid JSON from HTTP Request or Set node | String interpolation produced invalid quoting, trailing commas, or unescaped newlines. | Validate the exact body sent by the node, not the visual expression preview only. | Do not wrap an already-object value in extra quotes. | The downstream node receives valid JSON and the response status is expected. |
| IF branch changes data shape | True and false outputs carry different fields, item counts, or nested paths. | Inspect both IF outputs and define a shared normalized shape before merge/response. | Do not assume the true branch schema exists on false branch items. | Both branches feed the next node with the same required fields. |
| Code node returns wrong item format | Code returns a raw object/array instead of an array of items with json fields. | Check the Code node return value against the required item format. | Do not return secrets or full credentials for debugging. | The next node receives items shaped like [{ json: {...} }]. |
Recommended Steps
- Place the Set node before a node that needs a cleaner input shape.
- Choose which fields to add, rename, keep, or remove.
- Use expressions for values that come from earlier nodes.
- Keep only fields downstream nodes actually need when payloads are noisy.
- Run a test and inspect the exact output JSON.
Verification
- The output JSON has the exact field names downstream nodes expect.
- Unneeded fields are removed only after no downstream node needs them.
- Example items with missing fields still produce safe output.
Warnings
- Removing fields too early can break downstream expressions.
- Renaming fields without updating downstream mappings creates hard-to-see failures.
Common Mistakes
- Using Set as a place for complex logic better suited to Code.
- Renaming a field but leaving old expressions in later nodes.
- Keeping large unused fields and increasing memory pressure.
- Forgetting to test an item with missing optional fields.
Examples
email = {{$json.email}}
company = {{$json.company.name}}
source = webhook
created_at = {{$now}}
qualified = {{$json.score >= 80}}FAQ
Is Set the same as Code?
No. Set is best for straightforward field editing. Code is better for loops, complex transformations, and defensive logic.
Why did a later node lose data?
The Set node may be configured to keep only selected fields. Check whether needed fields were removed.