Lesson 1: What Is n8n? (Nodes, Triggers & Workflows Explained)

Introduction

Every developer has lived some version of the same morning: a lead lands in your inbox, and you copy a name into a spreadsheet, then retype the same three facts into a Slack message. Nothing about that work requires a human brain — it requires hands, and hands are the most expensive part of the process.

This is the exact problem n8n exists to solve, and it's worth understanding well because workflow automation has quietly become a core skill for developers. Companies don't just want engineers who can write code from scratch anymore — they want engineers who know how to connect systems that already exist, cut out manual busywork, and build reliable pipelines between tools that were never designed to talk to each other. If you've touched backend integrations, internal tooling, or DevOps, you've already brushed up against the ideas n8n is built on: events, triggers, data transformation, and execution logging.

This lesson is the foundation. Before you can build anything real in n8n, you need four concepts locked in: what a node is, how nodes become a workflow, what starts a workflow, and how you prove it actually ran. Get these four right and everything else in n8n — HTTP requests, conditionals, loops, error handling — is just variations on the same pattern.

Problem Overview

Picture a small business process: a new lead arrives by email, someone logs it in a spreadsheet for record-keeping, and someone else posts a summary in a team Slack channel so the sales team notices immediately.

Three tools — Gmail, Google Sheets, and Slack — each hold a piece of the picture, but none of them are aware the other two exist. Gmail doesn't know Sheets exists. Sheets doesn't know Slack exists. The only thing stitching them together is a person, doing the same three-step manual transfer every single time a lead comes in.

That manual stitching is the actual problem. It's not that the data is hard to get — it's that a human has become the integration layer between systems that should be talking directly to each other. n8n's job is to replace that human wiring with an automated, repeatable, observable process.

Example

Let's make this concrete with the exact scenario from the lesson:

1. A new lead email lands in Gmail.
2. The name and contact info get copied into a Google Sheet as a permanent record.
3. A short summary gets posted into a Slack channel so the sales team can act on it.

Manually, that's three separate actions, three separate app windows, and one person acting as the messenger between them. Automated with n8n, it becomes a single workflow: new lead detected → row added to sheet → message posted to Slack. The trigger, the middle step, and the final action are stitched together once, and after that, they run themselves every time a new lead shows up — no matter if it happens once a week or fifty times a day.

Intuition

Here's how an experienced engineer actually arrives at this solution, rather than just being told the answer.

Start by asking: what is actually changing hands here? Not tools, not UI — data. A name and an email address are being copied from one system's storage into two other systems' storage. That's it. Once you see it as data movement rather than "using an app," the solution becomes obvious: you don't need three humans clicking around three interfaces, you need one pipe that carries the data from the first system to the other two.

The next question an experienced engineer asks is: how do I break this pipe into pieces I can reason about independently? You don't want one giant tangled script that does everything at once, because when it breaks, you won't know which part failed. So you decompose the pipe into discrete steps — one step per action. That decomposition is exactly what a "node" is in n8n: one action, isolated, testable, and swappable.

Once you have discrete steps, order matters. "Add row" has to happen with the lead's data already available, so it must come after the lead arrives, and "notify Slack" is the last thing that should happen, since it's the human-facing summary of everything that already occurred. Chaining these ordered steps together is a workflow.

But a workflow sitting idle does nothing — something external has to kick it off. That's the role of a trigger: it's the event that says "start now," whether that's a new email arriving, a scheduled time of day, or a webhook ping from another system.

Finally, once something runs automatically and unattended, you lose the ability to just watch it happen. You need a record of what happened and when — which is why every run generates an execution log. Without it, debugging an automation that fails at 2 a.m. would be guesswork.

Nodes, workflows, triggers, and executions aren't four unrelated features — they're the natural decomposition of "replace a human doing repetitive multi-app work" into something a machine can run reliably and you can debug when it doesn't.

Brute Force Solution

The "brute force" version of this problem is simply not automating it — a human repeats the copy-paste-type sequence manually every time a lead comes in.

Idea: A person monitors Gmail, and on seeing a new lead, manually transcribes the relevant fields into Sheets and Slack.

Algorithm:

1. Watch inbox for new leads.
2. On arrival, extract name and contact details.
3. Open Sheets, paste into a new row.
4. Open Slack, type a summary message, send.

Advantages:

• Zero setup cost — no tooling, no learning curve.
• Full manual judgment on edge cases (e.g., deciding a lead looks like spam).

Disadvantages:

• Doesn't scale — every additional lead costs the same amount of human time.
• Error-prone — manual retyping introduces typos and dropped fields.
• No log — if a lead gets missed, there's no record showing where the process broke.
• Bottlenecked by availability — nothing happens if the person is offline or asleep.

Time complexity: O(n) human-minutes per n leads, with a high constant factor. Space complexity: O(1) additional storage beyond what Gmail, Sheets, and Slack already hold — but effectively unbounded "space" in the sense of someone's attention and time.

Optimal Solution

The optimal solution is the n8n workflow itself, and it's optimal because it replaces linear human effort with a fixed one-time setup cost.

Here's the shape of it:

Stage	Role	Example
Trigger	Starts the workflow	New email received in Gmail
Node 1	First action	Extract lead name/email from message
Node 2	Second action	Add a row to Google Sheets
Node 3	Third action	Post a summary message to Slack
Execution	Proof of run	Log entry showing exact data that flowed through

The key mental model, straight from the lesson: watch the data move left to right. It enters at the trigger, gets read and possibly reshaped at each node, and lands at the final action. Nothing here is "magic" — it's a value getting passed and transformed one step at a time, the same way data flows through a pipeline of functions in code.

Two design decisions matter for building this well:

One workflow, one job. A workflow trying to do five unrelated things at once becomes impossible to debug — when it breaks, you won't know which of the five jobs caused it. Keep each workflow scoped to a single clear purpose, the same discipline you'd apply to writing a single-responsibility function.

Pick your trigger deliberately. A trigger can be a schedule (run at 9 a.m. daily), a webhook (another app pings n8n when something happens), or a manual click. The trigger type shapes the whole workflow's behavior — a scheduled trigger checks for changes periodically, while a webhook trigger reacts instantly.

Python Code

n8n itself is a visual, node-based tool — you're not writing Python inside it for basic workflows. But it's useful to see the equivalent logic in Python, since it reveals that a workflow is fundamentally a small, ordered function pipeline with a triggering condition:

from dataclasses import dataclass, field
from datetime import datetime


@dataclass
class Execution:
    """Represents one workflow run and what data flowed through it."""
    workflow_name: str
    started_at: datetime = field(default_factory=datetime.now)
    steps: list = field(default_factory=list)
    status: str = "running"

    def log_step(self, node_name: str, data: dict) -> None:
        self.steps.append({"node": node_name, "data": dict(data)})

    def finish(self, status: str = "success") -> None:
        self.status = status


def extract_lead(data: dict) -> dict:
    """Node 1: pull the fields we care about from the raw event."""
    return {"name": data["name"], "email": data["email"]}


def add_row_to_sheet(data: dict) -> dict:
    """Node 2: simulate writing a row to a spreadsheet."""
    print(f"Sheet row added: {data['name']} <{data['email']}>")
    return data


def notify_slack(data: dict) -> dict:
    """Node 3: simulate posting a Slack message."""
    print(f"Slack: New lead - {data['name']}")
    return data


def run_new_lead_workflow(trigger_data: dict) -> Execution:
    """The workflow: an ordered chain of nodes, with a logged execution."""
    execution = Execution(workflow_name="new_lead_notification")

    data = extract_lead(trigger_data)
    execution.log_step("extract_lead", data)

    data = add_row_to_sheet(data)
    execution.log_step("add_row_to_sheet", data)

    data = notify_slack(data)
    execution.log_step("notify_slack", data)

    execution.finish("success")
    return execution


if __name__ == "__main__":
    # Simulated Gmail trigger firing with a new lead
    incoming_lead = {"name": "Jordan Lee", "email": "jordan@example.com"}
    result = run_new_lead_workflow(incoming_lead)

    assert result.status == "success"
    assert len(result.steps) == 3
    assert result.steps[0]["node"] == "extract_lead"
    assert result.steps[-1]["data"]["name"] == "Jordan Lee"
    print("Execution log:", result.steps)

Code Walkthrough

• Execution mirrors n8n's execution log — it records the workflow name, when it started, every step's output, and a final status, exactly like opening a failed execution in n8n's UI to see where it broke.
• extract_lead, add_row_to_sheet, and notify_slack are each a node — one isolated action with a single responsibility, no knowledge of what happens before or after it.
• run_new_lead_workflow is the workflow — it chains the nodes in a fixed order and passes the return value of one node as the input to the next, mimicking n8n's left-to-right data flow.
• The incoming_lead dictionary being passed into run_new_lead_workflow stands in for the trigger firing — in n8n this would be Gmail detecting a new message and kicking off the run automatically.
• execution.log_step after every node call is what makes debugging possible later — without it, a failure gives you no information about which step broke.

Dry Run

Trace run_new_lead_workflow({"name": "Jordan Lee", "email": "jordan@example.com"}):

1. Execution is created with status="running" and an empty steps list.
2. extract_lead runs, returning {"name": "Jordan Lee", "email": "jordan@example.com"}. Logged as step 1.
3. add_row_to_sheet prints the simulated sheet write and returns the same dict unchanged. Logged as step 2.
4. notify_slack prints the simulated Slack message and returns the dict. Logged as step 3.
5. execution.finish("success") sets status = "success".
6. The function returns the Execution object with three logged steps, each showing the exact data at that point — precisely what you'd see inspecting an n8n execution.

Complexity Analysis

Time complexity: O(k) per execution, where k is the fixed number of nodes in the workflow (here, k = 3). This is correct because each node runs exactly once per trigger event — there's no branching or looping over the lead data itself, just a straight chain.

Space complexity: O(k) for storing the execution log, since one log entry is kept per node. This is correct because the log's size scales only with how many steps the workflow has, not with the size of the incoming data (assuming each node's output is roughly constant size).

Compare this to the brute-force manual process: time cost there is O(n) human-minutes across n leads, since a person repeats the full sequence every time. The automated workflow's O(k) cost is paid once per event and doesn't grow with human attention — it grows with machine execution time, which is orders of magnitude cheaper.

Alternative Solutions

The most common alternatives developers evaluate are Zapier and Make — and the meaningful difference isn't features, it's the pricing and ownership model.

• Zapier / Make (task-based pricing): You're charged per task executed. Run the same workflow a thousand times, and you pay for a thousand tasks. This scales badly for high-volume automations, and if the vendor changes pricing, you have no way to move your workflows elsewhere — there's no server to take with you.
• n8n (workflow-based pricing, self-hostable): You're charged per workflow, not per run — executing it once or ten thousand times costs the same. You can self-host on your own infrastructure and own everything, or use n8n's cloud offering to skip maintenance, and either way you can migrate your workflows out whenever you choose.

The lesson's framing is worth internalizing: integration counts (six thousand apps vs four hundred) are a distraction if the platform can effectively hold your automations hostage through pricing or lock-in. The real question to ask when choosing a tool is "can I leave?" — and it's a question worth asking about any vendor dependency in your stack, not just automation tools.

Edge Cases

• Empty trigger data: What happens if a "new lead" event fires with a missing name or email? A production workflow needs a validation node before proceeding, or downstream nodes will silently write incomplete rows.
• Duplicate trigger fires: Some triggers (webhooks especially) can fire more than once for the same event. Without deduplication logic, you'd get duplicate Sheet rows and duplicate Slack pings.
• Trigger never fires: If the schedule or webhook is misconfigured, the workflow silently never runs — this is why checking execution history regularly matters, not just when something visibly breaks.
• A node fails mid-chain: If "add row to sheet" succeeds but "notify Slack" fails (e.g., API rate limit), you get an inconsistent state — the lead is logged but nobody's notified. The execution log is what lets you spot and reprocess this.
• High volume trigger bursts: A hundred leads arriving in the same minute — the workflow needs to handle concurrent executions without stepping on shared resources like a rate-limited API.

Common Mistakes

1. Building one giant workflow that does five unrelated jobs. Exactly the mistake called out in the lesson — when it breaks, you can't isolate which piece failed. Keep workflows scoped to one job.
2. Not checking execution logs after setup. A workflow can be "working" the first time you test it and then silently fail days later on an edge case you never hit during testing.
3. Choosing the wrong trigger type. Using a scheduled trigger when you actually need instant reaction (or vice versa) either delays automations that should be immediate or wastes resources polling when nothing changed.
4. Ignoring the pricing model until it's expensive. Task-based pricing tools feel cheap at low volume and become very expensive once a workflow scales — evaluate cost at your target volume, not your current one.
5. Skipping data validation between nodes. Assuming every upstream node's output is well-formed leads to downstream nodes failing on malformed or missing fields.
6. Self-hosting without a maintenance plan. Owning your infrastructure means owning uptime, updates, and backups too — going self-hosted without accounting for that trades vendor lock-in for a different kind of risk.

Interview Questions

• How would you design an idempotent workflow so retried trigger events don't create duplicate side effects?
• What's the tradeoff between a scheduled trigger and a webhook trigger for a given use case?
• How would you add error handling so a failure in one node doesn't leave downstream systems in an inconsistent state?
• How does workflow-based pricing change the cost model for a system with unpredictable or spiky traffic compared to task-based pricing?
• What would you log in an execution record to make a 2 a.m. failure debuggable without waking anyone up?

Similar Problems

• Designing an event-driven pipeline (systems design): Same core pattern — a trigger/event source, a chain of processing steps, and observability into what ran. Understanding n8n's model translates directly to designing message-queue-based systems.
• Building a CI/CD pipeline: A pipeline is also triggered (on push), runs an ordered chain of steps (build, test, deploy), and needs execution logs (build logs) for debugging — same shape, different domain.
• Writing a Unix pipeline (cmd1 | cmd2 | cmd3): Each command is a node, the pipe is the workflow's data flow, and the shell's exit codes are a crude execution log.

Key Takeaways

n8n replaces manual, repetitive cross-app work with four composable ideas: a node is one action, a workflow is an ordered chain of nodes, a trigger starts the chain, and an execution proves it ran and shows exactly what data moved through it. The technical model is simple by design — the real leverage is in the pricing and ownership story: paying per workflow instead of per task, and being able to self-host so you're never locked into a vendor's terms.

Watch the Video

For the full walkthrough with visuals of the workflow builder in action, watch the video here: {LINK}

About the Series

This lesson is part of Fun with Learning Technology, a series built for developers who want to actually understand the tools they use — not just click through a UI tutorial, but grasp the underlying model well enough to debug it at 2 a.m. when something breaks. Future lessons in this n8n track will build a real workflow from scratch, layer in conditionals and error handling, and cover self-hosting.

Call To Action

If this helped you understand n8n, drop a like on the video and subscribe on YouTube — the channel is small right now, and every subscribe genuinely moves the needle. For deeper written breakdowns like this one delivered straight to your inbox, subscribe to the Substack. And if you've got a question about triggers, workflows, or your own automation idea, drop it in the comments — I read all of them and future lessons often come directly from what people ask.

---