A workflow is a path

Every N8N workflow has the same shape: something starts it, data flows through nodes, and each node does one thing with what it receives.

Understanding how data moves between nodes is most of the skill. This article covers that.

Triggers

The trigger decides when a workflow runs, and it is the first decision you make.

Webhook. Another system calls a URL. Immediate, and the other system controls the timing.

This is how an e-commerce order sync works — the shop calls your webhook the moment an order is placed. It is also how a file upload from another tool arrives.

Schedule. Every hour, every night, every Monday. Simple and predictable.

Right for reference data that changes on a known rhythm, or for reconciliation jobs.

App event. N8N watches for a new email, a new row, a new record.

Manual. You press run. Useful while building, and for one-off jobs.

Choosing between webhook and schedule is the common decision. Ask what a delay actually costs. Real-time is more work to build and maintain, and many companies pay for it where fifteen minutes would have been invisible.

Items, and why they matter

The concept that confuses people, and it explains most unexpected behaviour.

Data in N8N moves as a list of items. Not one thing — a list.

If a node reads a CSV with 500 rows, the next node receives 500 items. And it runs 500 times, once per item.

That is usually what you want. Read 500 rows, create 500 records.

But it catches people out. A node that sends a notification, receiving 500 items, sends 500 notifications. If you wanted one summary, you need to combine the items first.

Two nodes solve this:

A merge or aggregate node turns many items into one.

A split node turns one item containing a list into many items.

When a workflow does something 500 times and you expected once, this is why. Look at what the previous node output.

Batching large files

Worth its own note, because it comes up on any bulk import.

Sending 500 records to an API one at a time is slow and it loads the target system unnecessarily.

Batching groups items — process 50 at a time, or send them in one call if the API supports it.

Two reasons to do this:

Speed. Fewer round trips.

Reliability. Fewer chances for a timeout, and less strain on the system you are writing to.

And a related decision: when a bulk import fails partway, should it stop or continue? Decide deliberately per workflow. Continuing means you finish the run and deal with the failures afterwards. Stopping means you know exactly where it got to.

Passing data between nodes

Each node can reference data from earlier nodes.

Three practical points:

Field names must match exactly. Case matters. This is the most common cause of a workflow that runs and produces nothing useful.

Missing fields do not always error. They may produce an empty value that flows on silently — worse than an error, because you find out later.

Look at the actual output. N8N shows what each node produced. Do not assume — check.

Branching

IF nodes send data one way or another based on a condition. Two outputs, and you connect different nodes to each.

Switch nodes handle more than two outcomes. Route by status, by type, by region.

Merge nodes bring branches back together.

A pattern that appears constantly: check whether a record already exists. If yes, use it. If no, create it. That single branch is what prevents duplicate customers on every import you will ever build.

Keep branching shallow. Three nested conditions is already hard to follow. If your logic needs more, the workflow is doing too much — split it.

Transforming data

Rarely does the shape coming out of one system match what the next one wants.

Set nodes define output fields explicitly. Cleanest, and easiest for somebody else to read.

Code nodes run JavaScript or Python for anything more complicated.

A useful rule: if a Set node can do it, use a Set node. Code nodes are more powerful and much harder for the next person to understand.

Error handling

The part people skip, and the part that matters most.

A workflow that fails silently is worse than no workflow, because everyone assumes it is running. You discover the gap weeks later and cannot reconstruct what was missed.

Four things on anything that matters:

An error workflow. N8N can run a second workflow when the first fails. Have it notify a person.

Retries. For anything calling an external API. Services have brief outages and a retry handles most of them.

Continue on fail, deliberately. Should one bad record stop the batch? Decide per workflow.

A visible failure route. Somebody must hear about it. Not a log file nobody opens.

Testing

Run it node by node. N8N lets you execute one node and see its output. Use this constantly while building.

Test with real data, including the awkward records — the row with a missing field, the name with an unusual character.

Test the failure path. Deliberately break something and confirm the alert arrives. An error workflow nobody has tested is not error handling.

Keeping workflows maintainable

Name nodes descriptively. Not “HTTP Request1”. Something that says what it fetches.

Add sticky notes. Explain why, not what — the what is visible on the canvas.

One workflow, one job. A workflow doing six unrelated things is impossible to change safely.

Give each one an owner. Somebody who can explain it in a year.

Credentials

Stored separately from workflows, which is right — you can share a workflow without sharing your passwords.

Two habits:

Use a dedicated account per integration, not a real person’s login. When they leave, the workflow should not break.

Give it the minimum access it needs. A workflow that only reads should not have write permission.

The short version

A workflow is a trigger followed by nodes, and data flows as a list of items — which is why a node sometimes runs 500 times when you expected once.

Batch large imports. Check before you create. Keep branching shallow.

And set up error handling before you go live. A workflow that fails quietly is the one that costs you.