The single word that explains most of the surprises

If you built the “push the calendar to Slack every morning” workflow in Part 6, you probably hit a few things that did not add up.

• The Google Calendar node runs once, reads back five events, and then the Slack node sends five messages — and nobody wrote a loop.
• In the Expression panel {{ $json.summary }} clearly has a value, but change it to {{ $json.items[0].summary }} and you get undefined.
• Google Sheets reads back an empty table and every node after it is skipped outright. No error is raised. It simply does not run.
• You add one field with a Set node and the output panel shows five rows, not the single row you expected.

All four have the same cause. What travels between one n8n node and the next is not a blob of JSON. It is a list of items, one record at a time. Zapier hides this from you. n8n lays it out in front of you, which is exactly why it can do more than Zapier and why it is harder for a beginner than Zapier.

That analogy is worth taking literally, because the vocabulary maps across almost exactly.

Then the rule that everything else follows from: the next node runs once for every single item. Google Sheets reads back 100 rows, so the Slack node sends 100 messages. That is not a bug. It is n8n's core behavior, and the official docs call it item-based execution.

The compartments inside an item

An item is not plain JSON. It is an object with a few fixed compartments. You will only use the first of them ninety-nine percent of the time, but knowing the other two exist saves you trouble later.

Laid out as data, one complete item has this shape:

So when the next node wants the name field, the path is $json.name. Note that it is $json.name and not $json.json.name — n8n strips that outer json layer for you, to keep expressions short.

Four expressions, and three ways to look at the output

Switch a node field into Expression mode — the gear or the = marker at the top right of the field — and you are in expression territory. For reading item data, only four forms are worth memorizing. Everything else is a variation on them.

$('Node Name') means “find that upstream node's output by its name”. The node name is the one you see on the canvas — double-click a node to rename it. The advantage of writing it this way is that even with a pile of Set and IF nodes in between, you can still reach straight back for the original data.

The output panel has three views, and one of them is underused

After you press Execute step on a node — running that one node on its own — or after the whole workflow finishes, the output panel on the right shows the items that node produced. Three view modes sit at the top, and each has its moment.

The top of the panel also shows the N items count. That is the number you will look at most while debugging. If it is not what you expected, something went wrong at that node, so trace upstream.

In the Table view, the small number in front of each row — 0, 1, 2 and so on — is the item index. To read a field on the first item you write $json.field, the item of the current iteration. Not $json[0].field. That is one of the most common beginner mistakes.

Two modes, one setting, and the question everybody asks in week one

How many times a node runs is decided by two things: how many items the input has, and the node's Execute Once setting. Most built-in nodes default to “as many runs as there are input items”, but you can change that.

To see or change which one a node uses, click the node to open its settings, switch to the Settings tab at the top, and find the Execute Once toggle. Turn it on and the node runs once using only the first item, however many items the input has. The rest are dropped.

Watch it happen across three nodes

Dizzy from the abstraction? Walk through the simplest possible three-node workflow once and it clicks: Manual Trigger, then Google Sheets reading rows, then Slack sending a message. Assume the sheet holds 5 rows of contacts.

flowchart LR
  A["Manual Trigger
runs once"] -->|"1 empty item"| B["Google Sheets
Read Rows
runs once"]
  B -->|"5 items"| C["Slack
Send Message
runs 5 times"]
  C -->|"5 items"| D["Five messages sent,
no loop written anywhere"]

Why does my workflow run once instead of five times?

This is the question beginners ask most in their first week. The cause is always one of three, and you can pin it down by reading the item count node by node in Executions.

Cause C is a nasty one, because “n8n items” and “a JSON field that happens to be called items” are two entirely different things. APIs very often return something shaped like this:

To expand that items array into 5 real n8n items, use the Split Out node, covered in Part 11, and point it at the items field. Only after that do you have 5 items, and only then does the downstream node run 5 times in a row.

flowchart TD
  A["It ran once. You expected five"] --> B{"Read the item count on
every node, left to right"}
  B -->|"the Trigger itself shows 1"| C["Cause A. Manual and Schedule
emit one empty item. The reading
node after them is what multiplies"]
  B -->|"5 goes in, 1 comes out"| D["Cause B. That node has Execute Once
switched on. Open the node,
Settings tab, turn it off"]
  B -->|"the count is 1 all the way"| E{"Schema view. Is it one item
holding an array?"}
  E -->|"yes"| F["Cause C. Add a Split Out node
and point it at that field"]
  E -->|"no"| G["The field name in the expression
is wrong. Read the real one
off the Schema view"]

When binary data comes up

Most business workflows never touch binary at all. Only nodes that deal with a file itself produce it.

• Gmail Trigger picks up mail with attachments, and they land in binary.attachment_0, binary.attachment_1 and so on.
• Google Drive Download puts the file content in binary.data.
• HTTP Request gets a PDF or image response and Response Format is set to File.
• Read/Write Binary File, which is only meaningful when you self-host.

To look at binary, switch to the Binary tab in the output panel. It is a fourth tab alongside Table, JSON and Schema, and it only appears when there is binary to show. It lists each binary's mime type, file name and size, and images even get a preview.

Something has to tell n8n when

You now know how data moves from node to node. Stop and ask the other question: when does a workflow actually start running? Only when you press the Execute Workflow button? Automatically at 8:00 every day? Or the moment a particular email arrives, or a particular URL is called?

Those three answers map onto n8n's three families of Trigger node. Every workflow has to pick one at the front — with no Trigger node, n8n has no idea when it is supposed to do the work for you. Picking the wrong one costs you directly: you wanted a daily run, you dropped in a Manual Trigger, and “why did nothing happen?” only surfaces a week later.

The On app event and On a schedule groups in the nodes panel hold dozens of Trigger nodes between them, but underneath they are variations on three types.

flowchart TD
  A["When should this workflow run?"] --> B{"Does a person decide,
every single time?"}
  B -->|"yes"| C["Manual Trigger.
Building, one-off jobs,
and human approval gates"]
  B -->|"no"| D{"A fixed time,
or an outside event?"}
  D -->|"fixed time"| E["Schedule Trigger.
Daily reports, hourly syncs,
Monday morning summaries"]
  D -->|"outside event"| F{"Does that service
offer a webhook?"}
  F -->|"yes"| G["Webhook, or a push trigger
such as Slack Trigger.
Reacts in a few hundred milliseconds"]
  F -->|"no"| H["A poll trigger such as
Gmail Trigger. Reacts on
whatever interval you set"]

Manual Trigger: your best friend while building

Manual Trigger is the simplest of all the triggers. It has no parameters at all — it is one node sitting there. One sentence covers how to use it: press Execute Workflow at the top right and the workflow runs once from the start.

Runs on its own, if you have told it whose 8:00 you mean

Schedule Trigger is the trigger automation uses most. You set a time rule and n8n runs the workflow for you when that time comes around: push the calendar to Slack at 8:00 in the morning, sync a database once an hour, send the weekly report at 9:00 every Monday. On the canvas it stands at the far left, and when the time comes it lights up everything downstream of it.

The Trigger Interval field is where you say how often.

Two setups cover most of what people actually want:

The timezone trap

This is the one that costs people half a day. Schedule Trigger reads the clock from the workflow's timezone setting, then falls back to the instance timezone. The documented self-hosted default is America/New_York, so “8:00” may not mean 8:00 where you are. It is a common n8n scheduling mistake and it is entirely avoidable.

There are two levels of timezone setting, and one overrides the other. Knowing which level you are editing is what saves you the half day.

The precedence is: workflow level, then instance level, then the documented America/New_York default. Which gives you three things to do, in this order.

1. Step 1

   Check the instance timezone instead of assuming it

   Ask the administrator whether GENERIC_TIMEZONE is set to an appropriate value. Or find out for yourself: build a test workflow, run it every minute, and check whether the times on the Executions page match the intended local time. If they do, the instance default is suitable — though an explicit workflow timezone is still safer when portability matters.

2. Step 2

   If they are wrong, set the workflow level

   Open the workflow's three-dot menu at the top right → Settings. There is a Timezone dropdown in the middle. Pick your IANA timezone and save when you are done.

3. Step 3

   Check every workflow that has a Schedule Trigger

   Workflow-level settings are independent of each other. Even with workflow A set, a new workflow B has to be set again if the instance level is something else.

When the outside world does the acting

Event triggers are the family that feels most like magic, because you are not the one acting — the outside world is. Someone fills in a form, mail arrives, a sheet is edited, someone pushes to GitHub, and n8n runs on its own. These are the ones you will meet most.

Webhook is the king of the family, because it takes anything that can call in over HTTP. Part 17 is entirely about it; for now it is enough to know it exists.

Why Gmail is always a beat behind

Underneath, event triggers split into two mechanisms, and that split is what decides how fast they react.

sequenceDiagram
  participant O as Outside service
  participant N as n8n
  Note over O,N: Push, the Webhook kind
  O->>N: Something happened, calling your URL
  N->>N: Workflow starts a few hundred milliseconds later
  Note over O,N: Poll, the Gmail Trigger kind
  N->>O: Anything new since I last asked?
  O-->>N: Nothing
  Note over O,N: the mail actually arrives about here
  N->>O: Anything new since I last asked?
  O-->>N: Yes, one message
  N->>N: Workflow starts, up to one poll interval late

So Gmail Trigger does not run the moment mail arrives. Every X minutes, n8n asks the Gmail API whether anything new has come in since it last asked. With a poll interval of 5 minutes, new mail waits up to 5 minutes before the workflow starts. To go faster, drop the poll interval to 1 minute — the shortest the Community edition allows — but you make more API calls and may run into the other side's rate limit.

One workflow can have several triggers

n8n lets you put several Trigger nodes on one workflow. They sit side by side, not in series — whichever one fires, the same downstream workflow runs. Three patterns are worth knowing.

flowchart LR
  A["Schedule Trigger
08:00 every day"] --> C["Downstream node A"]
  B["Manual Trigger
when you press the button"] --> C
  C --> D["Downstream node B"]

Hands-on: retiring the test trigger

Say the workflow you built in Part 6 starts with a Manual Trigger because you were testing. That was the right choice at the time. Now the testing is over and you want it to run by itself at 9:30 every morning.

1. Step 1

   Open that workflow

   Go in through the Workflows list on the left. Right now it starts with a Manual Trigger node, with your existing downstream nodes to its right.

2. Step 2

   Delete the Manual Trigger node

   Right-click the Manual Trigger node → Delete, or select it and press Delete or Backspace. The connection to the downstream nodes breaks and the first downstream node is left floating on the canvas. Do not panic; that is expected.

3. Step 3

   Add a Schedule Trigger

   Click + at the top left of the canvas, or press Tab on an empty spot, to open the nodes panel. Pick On a schedule → Schedule Trigger. It drops onto the canvas.

4. Step 4

   Set the time

   Open the node panel and set Trigger Interval to Days, Days Between Triggers 1, Trigger at Hour 9, Trigger at Minute 30. Look at the Next execution shown under the node and check that the timezone in parentheses is the one you intended. If it is not, set it as described in the previous section.

5. Step 5

   Connect it to your existing nodes

   Drag from the connector dot on the right of the Schedule Trigger to the dot on the left of the first downstream node. A successful connection shows as a solid line.

6. Step 6

   Save, then switch on Active

   Press Ctrl + S to save, then drag the Active toggle at the top right to green. This is the step everyone forgets. A Schedule with Active OFF never runs by itself, and finding that out tomorrow morning does not help you.

7. Step 7

   Verify with one manual run

   Once it is Active you can still press Execute Workflow for a manual run, which tests whether the Schedule Trigger path makes it all the way through. If that run succeeds, tomorrow at 9:30 it will fire on its own.

8. Step 8

   Check Executions the next day

   In Executions on the left, or the Executions tab inside that workflow, you will see the record of the automatic run at 9:30 the next day. A record means the schedule is alive. No record means go to the next section.

The faults you will actually hit, and what each one means

Two lists here, because the two halves of this part fail in different ways. First the item faults, then the trigger faults.

Items behaving oddly

• An expression shows undefined. Two possibilities. The field name is wrong — switch to the Schema view and read the real one, checking case, spaces and whether there is a data. prefix. Or the upstream node never ran successfully, in which case its output panel is empty or red. Fix the upstream node first, then worry about the expression.
• A node runs 100 times when you only wanted 1. That is because there are 100 items upstream. Three approaches: drop an Aggregate node in between to fold the 100 into 1; use a Code node, covered in Part 15, with return [ { json: { all: $input.all() } } ]; or, if you only want the first record, turn on Execute Once in that node's Settings — remembering that this means “take the first one”, not “combine them all”.
• The Merge node's item count does not add up. Merge has four modes and the wrong one changes the result completely. Append puts them end to end, so A's 3 plus B's 2 is 5. Combine then splits into three sub-options: Matching Fields compares field values like a SQL join, Position pairs up the same index, and All Possible Combinations is a Cartesian product, so A's 3 by B's 2 is 6. SQL Query (1.49.0 and later) lets you write the SQL yourself. Choose Branch emits the data from one side only. Older docs call All Possible Combinations Multiplex; the newer name replaced it, so do not panic when someone else's workflow still uses the old one. Part 11 goes into more detail.
• A node gets 0 items and is skipped. That is how n8n behaves: when the input is an empty array, the node does not run. It is deliberate, so you never have to write an empty check, but beginners read it as a broken node. Trace upstream to find who emitted 0 — usually neither IF branch passed, Google Sheets Read found no data, or a filter node filtered everything out.
• The item count is wrong after a Set node. The Set node runs once for each item by default, so the item count stays the same, and that is correct. If you see 5 in and 5 out but the fields have gone missing, the Set node's mode is usually on Keep Only Set, which wipes out the original fields. Try Include All Fields or Include Selected Fields instead. Part 13 takes the Set node apart in full.
• The expression preview does not match what actually runs. The expression editor previews against the upstream node's output from its last run. If the upstream node has not run yet, or ran wrong, the preview shows a stale value. Press Execute step on the upstream node to make it produce fresh output, then come back and look again.

Triggers not firing

Questions people ask

Where to go from here