The node that changes nothing except the shape

Part 7 of this series established the two facts everything here rests on: items are the unit that flows through n8n, and every item is a blob of JSON. Wire up a couple of SaaS nodes and you hit the consequence almost immediately — the two ends of a connection rarely agree about what that blob should look like.

A concrete version of the mismatch. The HTTP Request node hands back everything the API knows about a person:

You could hand-assemble ten lines of expression inside the Google Sheets node itself. You could open a Code node and write JavaScript for it every time. Neither is a good habit. What the workflow wants instead is a waypoint: one node between the two whose only job is to comb the upstream JSON into the shape the downstream node is asking for.

That is the Set node, and the “nothing leaves the house” part is worth stating precisely, because it is what makes the node safe to experiment with. It calls no API. It triggers no webhook. It has no effect on the outside world at all. It takes JSON, gives it a new shape, and passes it on.

Internally it is a small machine with three steps, and it repeats them for every item that arrives.

flowchart LR
  A["Previous node"] --> B["Read items"]
  B --> C["Rebuild JSON"]
  C --> D["Emit items"]
  D --> E["Next node"]
  X["No API call.
No webhook.
No side effect"] -.-> C

It runs once per item automatically, it is one of the fastest nodes in the product, and it usually finishes in milliseconds.

Manual Mapping or JSON, decided before you start

Open the node and the first thing at the top is a Mode dropdown with exactly two options. Everything else in the node changes depending on which one you pick.

Underneath, both modes do the identical thing: produce a new piece of JSON. The only real difference is whether you build it in a visual interface or type the JSON text yourself. If you are new to the node, start on Manual Mapping every time and switch to JSON only when you need a nested structure.

flowchart TD
  A["You need to change the shape"] --> B{"Does the output have to be nested,
or do you already have
a JSON template?"}
  B -->|"no"| C["Manual Mapping
add one field at a time"]
  B -->|"yes"| D["JSON mode
paste the whole template"]
  C --> E["Decide before you start.
Switching modes later
clears what you set"]
  D --> E

Combining two fields into one, step by step

Joining a first and last name into a single field is the most typical thing a Set node ever gets asked to do, so it makes the best first build. Assume the node upstream produces one item shaped like this:

You want one more field on the end called full_name, with the value Wang Xiaoming — last name first, because that is what this example's required output asks for. Choose an order and a separator that match your own users' naming conventions rather than copying this one blindly.

1. Step 1

   Add an Edit Fields node after the one producing that JSON

   On the canvas press + to add a node, search for edit fields or set, and pick Edit Fields (Set). Wire it directly after the node whose output you just looked at.

2. Step 2

   Leave Mode on Manual Mapping

   Manual Mapping is the default, so there is nothing to change here. You are adding one flat field, which is exactly what this mode is for.

3. Step 3

   Click Add Field under Fields to Set

   A blank field card appears underneath. Set its Type to String, because a name is a string.

4. Step 4

   Put full_name in the Name box

   This is the new field's name, and it is the exact name every downstream node will see in the JSON. Spell it the way you intend to refer to it later.

5. Step 5

   Put the expression in the Value box

   There is an Expression toggle at the top right of the Value field. Switch to Expression mode and paste this in:

   {{ $json.lastName }}{{ $json.firstName }}

   Two expressions, side by side, with nothing between them. $json means the JSON of the item being processed right now — Part 10 of this series covers the syntax in full.

   Read that last sentence literally, because it matters here. With nothing between the two expressions there is no space between the two values either. Exactly as printed above, full_name comes out as WangXiaoming — while the value asked for at the top of this section, and the output shown in Step 7, both read Wang Xiaoming, with a space. Those two do not agree. The expression is reproduced here character for character as the original tutorial gives it rather than quietly corrected, because the mismatch is the useful part: nothing supplies the separator for you. You type it, or it is not there.

   If you want the space, put a literal space between the two pairs of braces:

   With a space{{ $json.lastName }} {{ $json.firstName }}

   A comma and a space go in the same position; so does nothing at all, if the names you handle are written closed up. This is the point in the build where you choose the separator your own users' naming conventions want, and whichever you choose, every step after this one behaves identically.

6. Step 6

   Tick Include Other Input Fields

   Further down the node there is a toggle labeled Include Other Input Fields. Ticked, it keeps every original field and adds the one you just set. Unticked, it keeps only what you set and throws the rest away. Tick it here — the next section is entirely about this toggle, because it causes more confusion than the rest of the node put together.

7. Step 7

   Run Execute Node and read the output

   Press Execute Node at the top right of the node. The Output panel should show every original field still present, plus the new one:

   { firstName: "Xiaoming", lastName: "Wang", email: "...", age: 28, full_name: "Wang Xiaoming" }

   That is the output with a separator in the expression. Paste Step 5's expression exactly as it is printed and the same run gives you full_name: "WangXiaoming" instead — right in every other respect, and one keystroke away from either version. Read the Output panel rather than assuming; that is what it is for.

The five things Set gets used for most

Learn these five and you have covered the large majority of everyday Set node work. All of them are within reach of Manual Mapping — no Code node, nothing to install.

Most of the built-in JavaScript functions can be written directly in an expression: Number, String, Boolean, Math.round, Date, and string methods such as .toUpperCase(), .trim() and .split().

Include Other Input Fields, and why the docs disagree with your screen

This one toggle is responsible for more confused half hours than anything else in the node, so it gets a section of its own. Its behavior is not complicated. It is just that the consequence of getting it wrong shows up three nodes later, dressed as a different problem.

flowchart TD
  A["Input item
5 fields"] --> B{"Include Other Input Fields"}
  B -->|"ticked"| C["The 5 original fields
plus the 2 you set"]
  C --> D["7 fields go downstream"]
  B -->|"off"| E["Only the 2 fields listed
under Fields to Set"]
  E --> F["2 fields go downstream.
The other 3 are gone"]

Three situations, three answers:

• Adding or changing fields while keeping the rest. Tick it. This is the common case and the one you will use most days.
• A deliberate clean-out. You want exactly three fields to go downstream and nothing else — turn it off, then list those three fields under Fields to Set.
• Security. The upstream API response holds fields you do not want carried any further, such as a token or a password_hash. Turn the toggle off and let through only the safe ones.

Why the official docs say something else

In the older interface this toggle was called Keep Only Set Fields, and its logic was exactly reversed: ticked meant keep only what you set. From v1 it is Include Other Input Fields, where ticked means keep the others — which reads far more naturally, and which is why the change was made.

The wrinkle is that the official n8n documentation page still says Keep Only Set Fields to this day. So a docs page that does not match the wording on your screen is entirely normal here, and it is not a sign that you are looking at the wrong node. Go by what the UI in front of you says, and read the logic off the label rather than assuming it matches something you read elsewhere.

When the job is restructuring rather than tweaking

Manual Mapping gets clumsy the moment the output has to be nested. Say the upstream node gives you four flat fields — id, firstName, lastName, amount — and the API you have to call wants an orderId at the top level with a customer object beneath it holding a name and a vip flag. Building that one line at a time is where people get lost.

JSON mode settles it with a single paste.

1. Step 1

   Switch Mode to JSON

   Pick JSON in the Mode dropdown at the top of the node. Fields to Set disappears and a large text box takes its place.

2. Step 2

   Paste the template, expressions and all

   This is the whole template, written on one line so you can copy it exactly as it stands:

   { "orderId": "{{ $json.id }}", "customer": { "name": "{{ $json.lastName }}{{ $json.firstName }}", "vip": {{ $json.amount > 1000 }} } }

   Note the quoting, because it is the part that goes wrong. String values have to be wrapped in quotes — "{{ ... }}" — while boolean and numeric ones must not be. {{ $json.amount > 1000 }} evaluates to a bare true or false, and quoting it would turn a boolean into the string "true". The name line is the same two-expression join as Step 5 of the previous section, separator and all — written like this it produces no space, and a space typed between the two pairs of braces produces one.

3. Step 3

   Decide the Include toggle again

   JSON mode has the same Include Other Input Fields toggle. Most of the time you are in JSON mode precisely because you are restructuring, so you turn it off and keep only the fields the template defines.

4. Step 4

   Run Execute Node and check the structure

   The Output panel shows the structure you pasted with every expression already filled in with real values. Once the shape is right, wire up the downstream HTTP Request node and make the call.

Worked example: a nested API response into one sheet row

Now put the pieces together into something you would actually build. You called an order API with HTTP Request, what came back is nested three levels deep, and it has to be appended to an order-tracking sheet in Google Sheets as a single row.

The response looks like this, written as paths so the expressions are easy to read off:

The sheet's header row is Order ID | Name | Email | Amount | Timestamp | VIP. Six columns, so six fields.

flowchart LR
  A["HTTP Request
nested response"] --> B["Edit Fields (Set)
Manual Mapping
Include Other Input Fields off"]
  B --> C["6 flat fields named
like the sheet header"]
  C --> D["Google Sheets
Append one row"]

Click Add Field six times and fill them in against the header, column by column:

Run Execute Node and the output should be six purely flat fields, with no data wrapper left anywhere. Then wire up a Google Sheets Append node and set its Data Mode to Map Each Column Below. Because the field names already line up exactly with the header, you can drag the fields from the left panel straight into the matching boxes — no expressions to type a second time.

That naming trick is the point of the whole exercise. Sheets, Slack, Notion and Airtable are all fussy about field formats, and a Set node that hands them fields already named the way they want them turns a fiddly configuration into drag and drop.

Three nodes can reshape data. Only two are still on offer

If you have followed an older tutorial you will have met the Function node, and it is worth sorting the three out once so you never wonder again.

The question to ask, every time, is simply: can Set do this? If it can, use Set. Move up to Code only when it cannot. Set is visual, easy to read back, hard to get wrong and quick to run; Code can do more, but you write it, you handle its errors, and a non-engineer who inherits the workflow has a much harder time with it.

Four tricks worth knowing

1 · Nested fields with dot notation, without leaving Manual Mapping. Manual Mapping can produce a nested structure too. The trick is to build a path in the Name box using dots — set customer.name to {{ $json.firstName }} and customer.email to {{ $json.email }}, and the output is a customer object with those two keys inside it. It saves switching modes for a shallow nest.

2 · Many items in one pass, with no loop. Like every other node, Set runs once per item automatically. Send ten items in and you get ten reshaped items out. On each pass $json points at the item being processed right then, which is why the same single expression works for all of them.

3 · Continue On Fail, so one broken item does not stop everything. The Settings gear at the top right of the node holds Continue On Fail. When an expression fails on one item — a field that does not exist, so the path resolves to nothing — and this is off, the whole workflow stops in red. With it on, that item is marked as an error and the workflow keeps running: you can see in the output which items broke while the rest carry on downstream.

4 · A Set node at the front is a fake-data generator. No real trigger built yet, but you want to test the nodes after it? Drop in a Manual Trigger and a Set node, put the Set node in JSON mode, paste a block of fake JSON and turn Include Other Input Fields off. Pressing Execute Workflow now sends one made-up item down the whole chain. It is a lifesaver while debugging.

Eight things that go wrong, and what each one actually is

Almost every Set node problem announces itself the same way — something downstream is empty — and the cause is one of a small number of things. Work through them in this order rather than at random.

flowchart TD
  A["A field is missing
after the Set node"] --> B{"Is Include Other Input Fields
ticked?"}
  B -->|"no"| C["Tick it, or add that field
by hand under Fields to Set"]
  B -->|"yes"| D{"Does the output panel
show nothing for it?"}
  D -->|"yes"| E["The path is wrong. Run the upstream
node and copy the path
from its real output"]
  D -->|"no"| F{"Did you rename it?"}
  F -->|"yes"| G["Update every downstream expression
to the new name"]
  F -->|"no"| H["Check the Type and the quoting.
A number can arrive as a string"]

Questions that come up

Where to go from here