n8n Nodes and Workflows

Why it matters: n8n can be self-hosted and handles code-friendly logic, which makes it popular for AI and data workflows. Its item-based model surprises newcomers; learning it early avoids silent data bugs.

By the end you can:

• Describe a workflow as connected nodes passing items
• Distinguish triggers, actions, and logic nodes
• Read execution data to debug
• Choose error behavior deliberately

Learn (15 min)

1. Nodes and connections (5 min)

Trigger nodes start a workflow (webhook, schedule, app event). Action nodes do work in apps. Logic nodes (IF, Switch, Merge, Set, Code) route and transform. Connections define order. Before building the next node, check what the previous one emits.

2. Items and execution (5 min)

Data moves as items: a node receiving 10 items usually runs once per item and outputs results per item.

Input: [ {email:"a@x.org"}, {email:"b@x.org"}, {email:"oops"} ]
IF node (email contains "@") →
   true:  [a@x.org, b@x.org]
   false: [oops]

After a test run, open each node's output to confirm item counts and fields. Some settings change this behavior (run once vs. per item; returning no items stops the branch), so check them.

3. Credentials, environments, and errors (5 min)

Use n8n credentials instead of pasting secrets into nodes. Keep development and production workflows separate when you can. Pick error behavior on purpose: stop the workflow, continue with a defined fallback, or send failures to an error workflow that notifies an owner. "Continue on error" without a review path just hides failures.

Apply (15 min)

Worked example (3 min).

Form Trigger → Set (trim + lowercase email)
            → IF (email valid?)
                 true  → HubSpot: create/update contact → Slack: notify owner
                 false → Google Sheet: append to "Review queue"
Error workflow: any node failure → email owner with workflow name + execution link

Expected item after Set: { "email": "jane@firm.com", "name": "Jane Doe", "source": "headshot-form" }.

Lab (7 min): Trace the items.

1. Take the example above and write the input and output items at each node for three test submissions (valid, invalid email, duplicate).
2. Mark which node would break if the form sent an empty email field.
3. Decide the error behavior for the CRM node and justify it.

Deliverable: An item-by-item trace table for three inputs. You're done when: You can predict item counts at every node.

Check yourself (5 min)

1. What starts a workflow?
2. What is an item?
3. Scenario: The CRM node fails for 1 of 20 items. How should your workflow behave?
4. Where do credentials belong?
5. Why inspect execution data after a test?

Reference

Common mistakes

Cheat sheet: Trigger → inspect items → transform/branch → action → inspect execution → alert or recover.

Key terms: node, trigger node, item, execution, credential, error workflow.

Interview prompts: How do items differ from single records? How would you design failure handling for a CRM write?

Go deeper: n8n docs · Work with nodes · Handle errors gracefully · Security audit

Next: Lesson 14 — Zapier.