Choosing what to automate, triggers, the canvas, flow control, and keeping workflows tidy.
A Signal Through field guide. Independent, plain-English documentation; not affiliated with or endorsed by n8n GmbH. Approximately 23637 words.
In this volume:
Volume A gave you the mental model: workflows made of nodes, data flowing through them as items, executions as the record of what happened (see Chapter 3, The Core Mental Model). You have toured the workspace (Chapter 4) and built one small workflow end to end (Chapter 5). What Volume A could not give you is judgment — the habit of looking at a week of work and knowing which parts of it belong in a workflow and which parts do not. That judgment is a weekly practitioner skill, not a one-time decision, and it matters more than any button in the editor. A perfectly built automation of the wrong task wastes your time twice: once building it, and again every time it runs.
This chapter teaches that skill in three movements. First, how to spot automatable work and score candidates honestly. Second, how to map a chosen process into a written plan — trigger, steps, outcome — before you touch the canvas. Third, how to compare the three ways every n8n build can start: a blank canvas, an imported template, or an AI-generated draft. It closes with a worked selection exercise that produces the plan we will build, test, and ship across the rest of Volume B.
Automation candidates share a recognizable shape. The strongest ones show three signals at once.
Repetition. The task happens again and again in essentially the same form. Daily, weekly, every time a customer does something — the interval matters less than the sameness. If you could hand a new hire a checklist and they could do the task correctly on day one, it repeats in a way software can follow. If every occurrence is a fresh negotiation, it does not.
Rules. The decisions inside the task can be written down as conditions. "If the invoice is over the approval limit, send it to the manager; otherwise approve it." "If the form says 'enterprise', route it to sales; otherwise send the self-serve welcome." Rules are what n8n's flow-control nodes express directly (Chapter 9 covers branching and looping). Tasks that hinge on taste, relationships, or judgment calls that you cannot articulate resist automation — though, as Volume F shows, AI nodes have moved the line on what counts as "articulable." A task that needs some judgment can still be a good candidate if the judgment sits at one well-defined step: automate everything around it and leave a human (or a carefully constrained AI step) in the loop for that one decision.
Data movement. The task takes information from one place and puts it somewhere else, usually with a little reshaping on the way: copy the form submission into the spreadsheet, attach the invoice to the accounting record, post the new order into the team chat. Moving and reshaping data between systems is the single thing workflow automation does best, because every step is a node and every piece of data is an item the next node can read.
When all three signals appear together — repetitive, rule-based, data-moving — you have found a strong candidate. When only one appears, look harder before you build.
The mirror image is just as important. Be suspicious of candidates that are:
| Signal | Strong candidate | Weak candidate |
|---|---|---|
| Frequency | Daily, weekly, or per-event (per order, per signup) | A few times a year |
| Decisions | Expressible as if/then rules | Depends on taste, mood, or relationships |
| Data | Lives in apps with APIs or sends email/webhooks | Lives on paper, in heads, or in screenshots |
| Variation | Occurrences look alike | Every occurrence is a special case |
| Stability | Process unchanged for months | Redesigned constantly |
| Failure cost | Mistakes are annoying but recoverable | Mistakes are catastrophic and instant |
That last row deserves a note. High failure cost does not disqualify a task — some of the most valuable automations guard high-stakes processes — but it changes how you build: more testing (Chapter 10), more error handling (Chapter 23), more human confirmation steps, and a slower rollout.
Spotting candidates is easier when you hunt deliberately. Once a week, spend ten minutes on an automation diary: skim your sent email, your chat history, your browser tabs, and your calendar, and write down every task you performed more than once. For each, jot four things:
A rough score falls out naturally: frequency times duration tells you the ceiling on time saved; error cost tells you whether reliability alone justifies the build; input quality warns you how much cleanup logic (Chapter 18, The Transformation Toolkit) the build will need. Weigh that against build effort — which, after a few weeks with n8n, you will estimate in hours, not days, for most candidates.
Tip: The best first candidates are usually notifications and record-keeping, not decisions. "When X happens, tell the right person and write it down" is low-risk, high-visibility, and almost always a three-to-six-node workflow. Save the workflows that take consequential action — sending customer email, changing records of account, spending money — for after you trust your testing and error-handling habits.
Watch out: Do not automate a process you resent without asking why you resent it. Sometimes the honest answer is that the process should not exist at all. Automating a pointless task makes it permanent — it will now run forever, invisibly, at machine speed. Kill it or fix it before you encode it.
Once you have chosen a candidate, resist the urge to open the editor. The single highest-leverage habit in this entire compendium is writing the plan first, in plain sentences, on paper or in a note. Every workflow — no matter how elaborate — reduces to three parts, and your plan should name all three explicitly:
Trigger — what starts the work. Every run of an n8n workflow starts from a single trigger event: a schedule ("every weekday at 8:00"), an incoming webhook — a message another system pushes to a web address your workflow listens on ("when the form is submitted") — an app event ("when a new row appears"), or a manual click. Chapter 7 (Triggers) covers the full menu, including workflows that listen for more than one kind of event; at the planning stage you only need the sentence. Be precise about it, because vagueness here is the most common source of broken builds. "When we get a new lead" is not a trigger. "When someone submits the contact form on the website" is. If you cannot name the concrete, observable event that starts the process, you have not finished understanding the process.
Steps — what happens, in order. List the actions as numbered sentences, one action per line, each starting with a verb: "Look up the sender in the CRM" (the customer-relationship-management app where your contacts live). "Add a row to the tracking sheet." "Send a Slack message to the sales channel." Each sentence will roughly become one node. Where the process makes a decision, write it as a condition: "If the budget field is over the threshold, notify the senior rep; otherwise, send the standard reply." Conditions become branches (Chapter 9). Where the process waits — for a reply, for approval, for a day to pass — write that down too; waiting is a first-class capability in n8n, not a hack.
Outcome — what "done" looks like. Describe the finished state concretely: which records exist where, who has been told what, and what evidence proves the run succeeded. The outcome sentence becomes your test checklist in Chapter 10 and your monitoring definition in Chapter 25. If you cannot describe the outcome, you will not be able to tell whether the automation works — and neither will the workflow.
While you map, interrogate the current manual process with five questions:
The output of this exercise is what we will call a napkin spec: a trigger sentence, a numbered step list with conditions marked, and an outcome sentence. It fits on half a page. You will write one for every workflow you ever build, and the discipline pays off immediately: on the canvas, a napkin spec turns building into transcription. Without one, building becomes exploration, and exploration on the canvas is slow, because every wrong guess involves configuring, executing, and un-configuring real nodes.
Tip: Write the napkin spec as if instructing a competent temp who has never seen your business. If the temp would have to ask a question, the spec has a hole — and the workflow will hit that same hole at 2 a.m. with nobody to ask.
With a napkin spec in hand, you have three ways to turn it into nodes on a canvas. All three end in the same place — a workflow you have personally verified — but they trade off speed, learning, and correction effort differently.
| Starting point | Speed to first draft | What you learn | Correction effort | Best when |
|---|---|---|---|---|
| Blank canvas | Slowest | Most — you understand every node | None beyond your own mistakes | Learning; unusual processes; anything high-stakes |
| Template library | Fast | Moderate — you study someone else's choices | Swap credentials, replace placeholders, prune | Your process matches a common pattern |
| AI builder / assistant | Fastest | Least, unless you review deliberately | Highest variance — from trivial to total rework | Scaffolding common patterns; exploring what is possible |
The blank canvas is exactly what it sounds like: create a new workflow, add your trigger node, and build the chain one node at a time, testing each step as you go. Chapter 8 covers the canvas and node mechanics in depth, and Chapter 5 already walked you through the motions once.
Its cost is time; its product is understanding. Every node on the canvas is there because you put it there, configured to do a thing you decided it should do. When something breaks six months from now — and something will, because the apps at either end of your workflow change under you — you will debug a system you actually understand, which is a categorically different experience from debugging a system you imported.
Start from blank when the process is unusual (no template will match), when the stakes are high (you want no inherited surprises), or — especially early in your n8n journey — when the point is partly to learn. Through the rest of Volume B, we build from blank canvas for precisely this reason: the skills transfer to everything else, including the judgment you need to evaluate templates and AI output.
A template is a pre-built workflow that someone — the n8n team, a partner, or a community member — has published for others to copy. n8n maintains a large public gallery of them, browsable on the n8n website and reachable from inside the editor (look for the templates entry in the workspace navigation, or the option to start from a template when creating a new workflow). Templates range from two-node conveniences to elaborate multi-branch systems, and the gallery has grown into the thousands, with heavy coverage of popular apps and, in recent years, a flood of AI-agent patterns.
Templates are genuinely useful for two different jobs. The obvious one is a head start: if your napkin spec matches a common pattern — "form submission to CRM plus notification," "RSS to social post," "invoice email to accounting system" — someone has probably built it, and adapting their work is faster than building your own. The subtler job is education: reading a well-built template is one of the best ways to learn idiomatic n8n. Open one, follow the data from trigger to outcome, and you will pick up patterns — how experienced builders name nodes, where they put an edge-case branch, how they annotate with sticky notes (the canvas comment boxes covered in Chapter 8) — that would take weeks to discover alone.
Searching well. Search the gallery by the apps involved ("Stripe", "Google Sheets", "Slack") and by the job to be done ("lead", "backup", "digest"). App-based search is usually more precise, because the same job goes by many names but the app names are fixed. If your process involves two apps, search for the pair; a template that connects your exact pair is worth ten that connect one of them to something else.
Judging quality before you import. The gallery is a marketplace of varying quality, not a curated standard library. Before importing, weigh:
Importing and adapting safely. When you choose a template, the gallery offers to open a copy in your n8n instance (Cloud or self-hosted). The copy arrives as an ordinary workflow: editable, inactive, and entirely yours — changing it never affects the original. (Templates can also be shared as raw workflow JSON files; the mechanics of JSON export and import belong to Chapter 35, The Platform Surface.) Then adapt it with a fixed ritual, in this order:
YOUR_CHANNEL_HERE markers, example spreadsheet IDs,
their own test email addresses, and demo API endpoints throughout. Check
every node's fields — and check inside expressions (the
double-curly-brace formulas of Chapter 17), where a hardcoded ID can
hide in the middle of a formula. Miss one and the workflow runs
perfectly against the author's demo world instead of yours.Watch out: The riskiest template is one that almost matches your process. The 90 percent that fits lulls you into skipping the full read, and the 10 percent that does not fit is where it silently writes to the wrong system. Treat every imported template as untrusted until you have personally opened every node — the ten minutes this takes is the cheapest insurance in this book.
n8n ships two distinct AI helpers, and it pays to keep them straight.
The AI workflow builder generates workflows from a plain-language prompt. You describe what you want — "when a form is submitted on my site, look the person up in my CRM, add them if they are new, and post a summary to Slack" — and it drafts nodes on the canvas: a trigger, a chain of app nodes, sometimes branches, wired together and partially configured. It is a starting-point generator, and availability depends on your edition and plan (it arrived first on n8n Cloud; check your own instance rather than assuming).
The AI Assistant is a chat panel inside the editor. It answers questions about n8n, explains nodes, suggests expressions, and — most usefully — helps diagnose errors: when a node fails, you can hand the error to the Assistant and get a plain-language explanation and a suggested fix. It is a tutor and debugging partner rather than a generator, and it earns its keep most in Chapter 22's debugging craft. Its availability likewise varies by edition and plan.
(Both are features of the n8n editor that help you build. They are unrelated to the AI capabilities you build into workflows — the AI nodes and agents of Volume F.)
Prompting the builder well. The quality of a generated draft tracks the quality of your prompt, and your napkin spec is, conveniently, an excellent prompt. Name the specific apps ("Typeform", "HubSpot", "Slack" — not "my form tool"), state the trigger as an event, list the steps in order, and state conditions explicitly ("if the company field is empty, skip the CRM step"). Vague prompts produce generic scaffolds full of guesses; napkin-spec prompts produce drafts that mostly need configuration rather than redesign.
Honest guidance on what you will get. Generated workflows are drafts, and you should expect to correct them. The failure modes are consistent enough to make a checklist:
The correct posture, then, is neither dismissal nor trust: the builder is a fast typist with shallow knowledge of your business. It converts a clear spec into a scaffold in seconds, which is genuinely valuable — and then you apply exactly the same adaptation ritual as for a template from an unknown creator: read every node, attach credentials, fix values and expressions, add error handling, test before activating. If you cannot yet evaluate a generated workflow node by node, you are not ready to deploy one — which is the strongest argument for building your first several workflows by hand.
Tip: A productive middle path is to use the AI builder as a reconnaissance tool: prompt it with your napkin spec, study the draft to see which nodes and operations it reached for, then decide whether to adapt the draft or rebuild clean now that you know the shape. Even a flawed draft answers the expensive question "which nodes do I need?" in seconds.
A serviceable rule of thumb: blank canvas to learn or when stakes are high; template when your process is common; AI builder when your spec is clear and you are competent to audit the output. In practice, mature n8n users mix all three fluidly — skim the template gallery for prior art, prompt the AI builder to see a proposed shape, then build the real thing by hand, borrowing the good ideas from both. The starting method is a convenience, not an identity. What never varies is the ending: every workflow, however it began, gets the same read-through, the same credential and placeholder audit, and the same testing pass before activation.
Time to practice the whole chapter on a realistic case. Meet a small consultancy — three people, steady inbound interest, no dedicated operations staff. A week of diary-keeping surfaces four recurring tasks:
Score them with the audit lens. Proposal writing fails the rules test at its core. Social posting passes every test and fails the payoff test. Invoicing has real payoff but is a poor first project: low frequency means slow iteration (you learn from executions, and monthly means twelve per year), and its error cost is money leaving with your name on it. Inquiry handling is the standout: it is frequent (fast feedback while you learn), repetitive, rule-based (one clean decision: prospect or not), pure data movement, and its current failure mode — the forgotten lead — is exactly the reliability problem automation solves. Failure cost is modest and recoverable. This is the strong candidate, and choosing it — not building it — was the skilled move.
Now the napkin spec:
Trigger: A visitor submits the contact form on the website.
Steps:
Outcome: Every genuine inquiry appears in the tracking sheet within a minute of submission, the team has been notified in chat with enough context to act, and the inquirer has received an acknowledgment. Failures notify the team instead of dying silently.
Known edge cases: duplicate submissions from double-clicked forms; empty company fields; the prospect-versus-vendor rule needing tuning; the spreadsheet being unreachable mid-run.
Which starting method? A pattern this common certainly exists in the template gallery, and the AI builder would scaffold it competently from that spec. We will nonetheless build it from the blank canvas — because the point of Volume B is to make you the kind of builder who can audit the other two starting points. Chapter 7 chooses and configures the trigger for this spec and surveys the whole trigger landscape while it is at it. Chapter 8 teaches action-chain mechanics on the canvas, practicing first on a deliberately simplified, schedule-driven skeleton of this plan — read the new rows from the tracking sheet, post a formatted digest line for each to the team chat — before you assemble the full intake. Chapter 9 adds the branch and the edge-case handling. Chapter 10 tests it honestly, activates it, and keeps it tidy. And much later, Chapter 36 (Worked Project 1: The Lead Machine) revisits this same territory at full production depth — enrichment, scoring, follow-up sequences — so nothing you build now is throwaway.
One chapter of restraint before the canvas: that is the whole discipline. You now know how to find work worth automating, how to reduce it to a trigger, steps, and an outcome, and how to judge the three doors into a build. Bring the napkin spec to Chapter 7, and we will decide precisely when this workflow should wake up.
Every workflow in n8n begins with a trigger: a special node whose only job is to decide when an execution starts and what data it starts with. Everything downstream — the action chain, the branching, the error handling — is dormant until a trigger fires. That makes the trigger choice the first real design decision in any automation, and often the most consequential one. Pick the wrong trigger and you get a workflow that runs too often, too late, or not at all; pick the right one and half your reliability problems never exist.
This chapter is the chooser's guide. For each way a workflow can start, you get a plain-English profile — what it is, how it behaves, when to reach for it — without descending into deep configuration. Where a trigger deserves a whole chapter of its own (webhooks, error workflows, evaluations, sub-workflows), you get the concept here and a pointer to the chapter that finishes the job.
A quick grounding before the catalog. In the mental model from Chapter 3 (The Core Mental Model), a workflow is a chain of nodes that pass items — individual packets of data — from left to right. A trigger sits at the far left of that chain. It has no input connector, because nothing comes before it. When it fires, it produces the first items of the execution: the email that arrived, the form that was submitted, the timestamp of a schedule tick, or the payload another system pushed in.
Two properties of triggers matter more than anything else when choosing one:
There is one more distinction to hold in mind throughout: most triggers behave differently depending on whether the workflow is inactive (you are building and testing it in the editor) or active (you have flipped the activation toggle and the workflow runs in production on its own). The final sections of this chapter cover exactly what activation changes; the short version is that Manual and Execute Sub-workflow triggers do not care about activation, and everything else only truly listens once the workflow is active.
| Trigger | Fires when... | Typical first data | Reach for it when... |
|---|---|---|---|
| Manual | You click the test/execute button | Empty item or pinned test data | Building, testing, one-off runs |
| Schedule | A time interval or cron expression matches | A timestamp | Work happens on a rhythm, not in response to events |
| App event (polling) | A periodic check finds something new in an app | The new/changed records | The app has a trigger node but no push support |
| App event (instant) | The app pushes an event the moment it happens | The event payload | The app supports push and latency matters |
| Webhook | Any system sends an HTTP request to your URL | The request body, headers, query | You need a general-purpose endpoint |
| n8n Form | Someone submits a form n8n hosts for you | The form fields | You need human input and no form tool exists yet |
| Chat | Someone sends a message in a chat interface | The message and session info | You are building a conversational or AI-agent experience |
| Email (IMAP) | A new email lands in a monitored mailbox | The email (subject, body, attachments) | Email is the system of record and there is no better API |
| Execute Sub-workflow | Another workflow calls this one | Whatever the parent passes | You are building reusable workflow components |
| Error | Another workflow's execution fails | Details of the failed execution | You want centralized failure handling |
| Evaluation | An evaluation run feeds in a test dataset row | One dataset row per run | You are measuring AI workflow quality |
Now the profiles.
The Manual Trigger is the simplest possible answer to "when should this run": it runs when you tell it to, by clicking the execute button in the editor. It carries essentially no data of its own — the execution starts with a single empty item, which is fine, because the point of a manual workflow is usually that the nodes after it know what to do.
Its natural habitat is the build loop. While you are constructing an automation, you want to run it on demand, inspect the output of each node, fix something, and run it again — the rhythm Chapter 10 (Test, Fix, Activate, and Keep It Tidy) is built around. Many builders start every new workflow with a Manual Trigger, get the action chain working, then swap in the real trigger at the end.
But the Manual Trigger is not only scaffolding. Some automations are genuinely manual forever: a data cleanup you run quarterly, a report you generate when someone asks, a migration script you fire once and archive. If a human decision is the correct starting gun, a Manual Trigger is the correct trigger — there is no rule that says every workflow must eventually run itself.
Selection guidance: use it for building, testing, and truly on-demand work. Do not contort it into production duty by leaving yourself calendar reminders to click a button — that is what the Schedule Trigger is for.
The Schedule Trigger fires on a rhythm you define: every five minutes, every day at 07:00, the first Monday of each month. When it fires, the execution starts with a single item containing little more than the current timestamp — the trigger tells you that it is time, and your downstream nodes go find out what needs doing.
For simple rhythms, the node offers friendly interval options — every N seconds, minutes, hours, days, weeks, or months, with a "at what time" refinement — and you may never need more. For anything irregular ("weekdays at 8:30 and 17:30", "the 1st and 15th"), you drop into a cron expression, a compact scheduling language inherited from decades of server administration. It looks like line noise the first time you see it, so let's decode it properly.
A classic cron expression is five fields separated by spaces, read left to right:
┌───────── minute (0–59)
│ ┌─────── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌─── month (1–12)
│ │ │ │ ┌─ day of week (0–7, Sunday = 0 or 7)
│ │ │ │ │
* * * * *n8n also accepts a sixth field in front for seconds, if you need sub-minute precision — but start by mastering the five, and note that most online cron checkers expect exactly five fields, so drop the seconds column before pasting an expression into one to verify it.
Each field accepts a small vocabulary:
* means "every value" — every minute, every hour,
whatever the field is.30 in the minute
field means minute 30.1,15 in the
day-of-month field means the 1st and the 15th.1-5 in the
day-of-week field means Monday through Friday.*/10 in the minute field
means every ten minutes (minute 0, 10, 20, and so on); writing
0/10 expresses the same rule while naming minute 0 as the
explicit starting point.Read a few and the pattern clicks:
| Expression | Plain English |
|---|---|
0 7 * * * |
Every day at 07:00 |
30 8 * * 1-5 |
Weekdays at 08:30 |
*/15 * * * * |
Every fifteen minutes |
0 9 1,15 * * |
09:00 on the 1st and 15th of every month |
0 0 * * 0 |
Midnight every Sunday |
Watch out: n8n follows the classic cron rule for the two "day" fields: if you set both day-of-month and day-of-week to something other than
*, they are treated as an OR, not an AND.0 9 13 * 5fires at 09:00 on the 13th of the month and on every Friday — not only on Friday the 13th. There is no cron syntax for a true AND of the two; if you genuinely need "Friday the 13th", let the schedule fire on the broader condition and add a downstream check for the rest. And if a schedule seems to fire more often than you expected, this is the first thing to check.
"Every day at midnight" is ambiguous until you say where.
Schedule Triggers resolve times against a timezone, and n8n gives you
two layers of control: the instance has a default timezone (on
self-hosted installs this is set by an environment variable, typically
GENERIC_TIMEZONE; on n8n Cloud it lives in your instance
settings), and each individual workflow can override it in the
workflow's own settings panel
(Workflow Settings > Timezone, reached from the menu in
the editor's top bar). The Schedule Trigger uses the workflow's
timezone, falling back to the instance default.
This matters most in three situations: your server runs in UTC but your business runs somewhere else; your team spans regions and "9 a.m." means different things to different stakeholders; and daylight saving time. On DST transition days, an hour of the clock either repeats or vanishes — a schedule set for a time inside the vanished hour simply does not have a real moment to fire in that day, and one inside the repeated hour may behave oddly. If a job absolutely must run exactly once a day regardless of clock politics, schedule it in UTC or at an hour DST never touches.
Here is the semantics question almost nobody asks until it bites them: if your n8n instance is down — restarting, upgrading, crashed — at the moment a schedule was due, what happens when it comes back?
The answer: nothing. The run is skipped. Schedule Triggers are live timers, not a durable job ledger; n8n does not keep a list of "runs that should have happened" and backfill them on startup. When the instance restarts, the schedule resumes from the next future occurrence.
The design consequence is important enough to state as a rule: make scheduled workflows self-catching. Instead of "fetch the last hour of orders" every hour, build "fetch all orders since the last one I successfully processed" — by recording a high-water mark (the newest timestamp or ID you have handled, stored somewhere durable such as an n8n Data Table, covered in Chapter 20). A self-catching workflow shrugs off a missed run: the next run simply picks up a slightly bigger batch. A "last hour" workflow silently loses an hour of data forever. Chapter 24 (Reliability Patterns) develops this idea fully.
Selection guidance: use the Schedule Trigger when work is driven by the calendar, or as a deliberate polling rhythm when no event-based trigger exists for your source system. Prefer event-driven triggers when they are available — a schedule that runs every five minutes to ask "anything new?" makes 288 executions a day to catch events an instant trigger would have delivered for free.
Open the node picker and search for almost any well-known app — a CRM, a spreadsheet, a chat platform, a payment provider — and alongside its action nodes you will usually find a dedicated trigger node: "on new row", "on updated deal", "on new message". These app event triggers are the workhorses of everyday automation, because most business automations are reactions: when a lead arrives, when a payment lands, when a file changes.
Under the hood, every app event trigger works one of two ways, and knowing which one you have changes what you should expect from it.
Polling triggers check the app on a repeating schedule — n8n calls the app's API, asks "anything new since last time?", remembers where it left off, and fires with whatever appeared. Polling is universal (any API that can be queried can be polled) but it has an inherent latency: events are detected no faster than the poll interval, which you can usually adjust in the trigger's settings. Polling triggers only do their periodic checking while the workflow is active; while you are testing in the editor, they do a one-off "fetch a recent event" so you have realistic data to build against.
Instant triggers (webhook-push triggers) work the other way around: when you activate the workflow, n8n registers a webhook — a URL the app should call — with the app itself, and the app pushes each event to n8n the moment it happens. Latency drops to near zero and no polling traffic exists at all. The trade-off is dependency: the app must support outbound webhooks, the registration must succeed, and if the app ever silently drops the registration, events stop arriving with no error on your side. Some app triggers are labeled with words like "instant" in the picker; others reveal their nature only in their settings (a poll-interval setting is the giveaway of a polling trigger).
| Polling trigger | Instant trigger | |
|---|---|---|
| Who initiates | n8n asks the app repeatedly | The app pushes to n8n |
| Latency | Up to one poll interval | Seconds or less |
| API traffic | Constant background checks | Only real events |
| Missed-event risk | Low (next poll catches up) | Higher (a dropped push is gone unless the app retries) |
| Requirements | App has a queryable API | App supports outbound webhooks |
Tip: When both variants exist for the same app, choose instant for speed and polling for robustness. A polling trigger that runs every few minutes is often the calmer choice for business processes where a five-minute delay is invisible but a silently dead webhook registration would be a quiet disaster.
Selection guidance: if the app you care about has a trigger node, start there before considering the generic Webhook node — the app trigger handles authentication, event subscription, and payload parsing that you would otherwise wire by hand.
The Webhook node is the general-purpose front door. It gives your workflow a URL, and any system on the internet that can make an HTTP request — which is essentially every system — can start your workflow by calling it, passing whatever data it likes in the request. Where an app event trigger is a pre-built receiver for one specific app's events, the Webhook node is a blank receiver you shape yourself: your URL, your expected payload, your response.
You reach for it when the calling system is not in the integration catalog, when you are wiring two of your own services together, when a vendor offers "we can POST to a URL you give us", or when you want n8n to be the API (Chapter 14 shows how far that idea goes).
The one concept you must internalize now — because it confuses every newcomer — is the test URL versus production URL distinction. Every Webhook node exposes two URLs:
Give an external system your test URL and it will work exactly once, while you happen to be watching, and then mysteriously go dead — a rite of passage nearly everyone experiences once.
Watch out: When you copy a webhook URL to paste into another system, check which tab you copied it from. The two URLs differ (typically by a path segment such as
webhook-testversuswebhook), and pasting the test URL into a production configuration is the single most common webhook mistake in n8n.
Everything else about webhooks — methods, responses, authentication, payload handling, security — is Chapter 14 (Webhooks In Depth) territory. For choosing purposes: Webhook when you need a general endpoint; app trigger when a purpose-built one exists.
The n8n Form Trigger starts a workflow when a person submits a web form — and, unusually, n8n hosts the form for you. You define the fields (text, dropdowns, dates, file uploads and so on) in the trigger node, and n8n generates a shareable web page. No website, no form vendor, no embed code required. Submissions arrive as items whose fields match your form fields exactly, which makes the downstream chain unusually clean: the data is already named and shaped the way you designed it.
Like the Webhook node it is built on, the Form Trigger has a test URL (for watching submissions land while you build) and a production URL (live once the workflow is active) — same distinction, same rite of passage. Multi-step forms are possible by adding further Form pages later in the workflow, which turns a workflow into a small guided wizard, but that is beyond a chooser's guide.
Selection guidance: reach for the Form Trigger when the missing ingredient in an automation is structured human input — an intake request, an approval with a reason, a survey, an internal tool's front end — and standing up a separate form product would be overkill. If your organization already runs forms elsewhere, using that app's event trigger keeps one fewer surface to maintain; the n8n form shines when you want zero extra moving parts.
The Chat Trigger starts a workflow when a message arrives in a chat interface — either the built-in chat panel you use while building, or a hosted/embeddable chat widget you can expose to real users. Each incoming message starts an execution carrying the message text and a session identifier, so multi-turn conversations can be stitched together.
In practice the Chat Trigger is the standard front door for AI agent workflows: pair it with the AI Agent node (Chapter 28) and you have a conversational assistant, with the Chat Trigger handling the "when a user says something" half and the agent handling the thinking. Nothing requires AI behind it — it is just a trigger that emits messages — but conversation is the use case it was built for.
Selection guidance: choose the Chat Trigger when the interaction model is a conversation. If you merely need a message notification from a chat platform your team uses, that platform's own app trigger is the better fit; the Chat Trigger is for when n8n itself is hosting the conversation. The AI chapters (Volume F, especially Chapters 26 and 28) take it from here.
The Email Trigger (IMAP) watches a mailbox and starts an execution for each new email, delivering subject, sender, body, and attachments as the first item. IMAP — the Internet Message Access Protocol — is the decades-old standard for reading a mailbox remotely, which is precisely its charm: it works with nearly any mail provider, including ones with no modern API at all. Under the hood it behaves like a polling trigger pointed at your inbox.
Its natural use cases are the places where email is the
integration: a vendor who sends CSV reports as attachments, an inbound
address like invoices@yourcompany.com that feeds a
processing pipeline, legacy systems whose only output channel is mail.
Parse the email, extract the payload, and the rest of the workflow
proceeds as if a real API had called you.
Selection guidance: if your mail lives on a major provider that has its own dedicated trigger node in the catalog, prefer that node — provider-specific triggers authenticate more smoothly (modern providers increasingly restrict plain IMAP access) and understand labels, threads, and folders natively. Reach for the IMAP trigger when the provider is generic, self-hosted, or otherwise uncatalogued. Either way, decide early what happens to processed mail (mark read, move, label) so the same message is not handled twice — an idempotency concern (repeated input, no repeated effect) that Chapter 24 returns to.
The Execute Sub-workflow Trigger (shown in the node picker with wording like "When Executed by Another Workflow") is how a workflow declares itself callable. A parent workflow uses an Execute Sub-workflow node to invoke the child; the child's trigger receives whatever items the parent passes, the child runs, and its final output returns to the parent, which continues on. If a normal trigger is a doorbell, this one is an internal extension line between your own workflows.
This is the trigger of composition — the mechanism behind reusable building blocks: one workflow that normalizes addresses, one that posts notifications, one that wraps a fussy API, each called from many parents instead of being copy-pasted into them. The trigger node can also declare what input fields it expects, functioning as a small contract between caller and callee.
Two properties worth knowing at the chooser level: a workflow whose only trigger is this one never fires on its own — no schedule, no outside event, only calls; and it does not need to be active to be called, since a parent invokes the child's saved definition rather than its activation state. The full design craft — when to split a workflow, how to shape the contract, error propagation between parent and child — lives in Chapter 9 (Flow Control), and you will see it used throughout the worked projects in Volume H.
Selection guidance: reach for it the second time you catch yourself copy-pasting the same node chain into another workflow.
The Error Trigger starts a workflow when some other workflow's execution fails. You build a workflow beginning with an Error Trigger — post to the team channel, log the failure, open a ticket — and then, in each production workflow's settings, designate it as that workflow's error workflow. From then on, a failed execution anywhere among those workflows starts your error workflow, handing it an item describing what failed: which workflow, which execution, which node, and the error message, with a link back to the corpse for autopsy.
Its profile is unusual in two ways. First, it is reactive to the platform itself rather than to the outside world — the "event" is a failure inside n8n. Second, it is a hub: one error workflow typically serves many production workflows, which is exactly the point. Centralized failure handling means one place to improve your alerting instead of thirty.
Selection guidance: this is not really a trigger you choose for a task — it is one you should install as a matter of hygiene before anything important goes live. Even the minimal version (Error Trigger, then one notification node) converts silent failures into visible ones, and silent failure is the default failure mode of automation. Chapter 23 (Error Handling) covers the depth: what data arrives, how error workflows interact with retries and error branches, and patterns for triage at scale.
Tip: Build your first error workflow the same day you activate your first real workflow. It takes minutes, and the first time it fires, it pays for every workflow you ever build afterward.
The Evaluation Trigger exists for one specialized purpose: testing AI workflows against a dataset. Instead of firing on time or events, it feeds your workflow rows from a test dataset — one row per run — so the same workflow logic can be executed across many known inputs and its outputs scored against expectations. It is the harness that lets you ask, with numbers, "did my prompt change make the workflow better or worse?"
If you are not yet building AI workflows, file this one away. If you are, the profile to remember is: it sits alongside your normal trigger (a workflow commonly has both a Chat or Webhook trigger for production and an Evaluation Trigger for test runs), it fires only during evaluation runs rather than in production traffic, and it is one half of a system whose other half — scoring, metrics, comparing runs over time — is Chapter 30 (Trustworthy AI) territory.
Selection guidance: reach for it once an AI workflow matters enough that "it seems fine when I chat with it" stops being an acceptable quality bar.
A workflow is not limited to one trigger. You can place several trigger nodes on the same canvas — say, a Schedule Trigger for a nightly sweep and a Webhook for on-demand runs, or a Chat Trigger beside an Evaluation Trigger — and each one independently starts executions of the workflow.
The rules of the arrangement are simple:
Selection guidance: multiple triggers earn their keep when the same logic genuinely serves multiple entry points — nightly-plus-on-demand is the classic — or when a specialized companion trigger (Evaluation, most commonly) rides alongside the production one. If the chains behind two triggers share nothing, they are two workflows cohabiting a canvas, and Chapter 10's tidiness advice says to split them.
The activation toggle — the switch in the editor's top bar that turns a workflow Active — is where trigger behavior forks, so let's make the two worlds explicit.
While inactive, a workflow runs only when you explicitly execute it in the editor. Manual Triggers work; other triggers offer editor-friendly stand-ins — a webhook's test URL listens for one call when you ask it to, a polling trigger fetches a sample recent event, a Form or Chat trigger serves its test surface — all designed to hand you realistic data to build against, with results displayed live on the canvas.
Once active, the workflow runs itself. Schedule timers are armed. Polling triggers begin their periodic checks. Production URLs (webhook, form, chat) go live and stay listening. Instant app triggers register their webhooks with the external app. Executions now happen unattended — in the background, on the server — and are recorded in the executions list rather than played out in front of you. Saving further edits to an active workflow updates what future executions will run, which is why Chapter 10's discipline of test-then-activate matters.
Two triggers stand apart from this fork: the Manual Trigger, which is editor-only by nature and does nothing in an active workflow's background life, and the Execute Sub-workflow Trigger, which fires when called by a parent regardless of the toggle.
Watch out: "It worked when I tested it and stopped when I walked away" is almost always an activation story: the workflow was never activated, or an external system was given the test URL instead of the production one. Check the toggle and the URL before debugging anything deeper.
When you are staring at the node picker unsure where to begin, walk this ladder:
The trigger determines the tempo and the raw material of everything that follows. With the when settled, the next question is the what — building the chain of actions behind the trigger, which is exactly where Chapter 8 (Building the Action Chain) picks up.
You arrive at this chapter with a plan and a trigger decision. Chapter 6 produced the napkin spec — when a visitor submits the website contact form, record the inquiry, tell the team, acknowledge the sender — and Chapter 7 settled how workflows wake up. What you do not yet have is the muscle memory: how to actually assemble a workflow on screen, wire nodes together, open one up, fill in its parameters, and feed data from one step into the next. That is this chapter's whole job. By the end you will have built the real, linear trunk of that spec — trigger, record, notify, acknowledge — and you will know the editor well enough that the mechanics stop being something you think about.
A quick vocabulary anchor before we start, compressed from Chapter 3 (The Core Mental Model): a workflow is the automation you are building; a node is one step inside it; a connection is the line that carries data from one node to the next; and the canvas is the large gridded surface where you arrange all of this. Everything in this chapter happens on the canvas or inside a node.
Start from the workflows list — the home screen you toured in Chapter
4 (A Guided Tour of the Workspace). Look for the create button, usually
labeled Create Workflow in the top-right corner of the
overview page. Clicking it drops you onto a fresh canvas containing a
single prompt to add your first step.
Name the workflow immediately. The name lives at the top-left of the editor; click it, type something you will recognize in three months, and press Enter. "My workflow 3" tells future-you nothing; "Website inquiry intake" tells you everything. Naming is cheap now and expensive later, because once you have forty workflows, the list view is your only map.
Save early and often with Ctrl+S (or Cmd+S
on a Mac — from here on, read Ctrl as Cmd if
you are on macOS). n8n keeps your edits in the browser as you work, but
a save is what writes a durable version. The editor shows whether you
have unsaved changes near the workflow name; get in the habit of
glancing at it before you close a tab.
The canvas is effectively infinite, and workflows sprawl, so panning and zooming are constant companions:
Space and dragging,
dragging with the middle mouse button, or Ctrl-dragging
with the left button. On a trackpad, a two-finger scroll pans too.Ctrl plus the mouse wheel,
or the + and - keys. Press 0 to
reset the zoom level, and 1 to zoom out just enough to fit
the whole workflow on screen.That 1 key is worth internalizing on day one. Any time
you feel lost — too deep in a corner of a big workflow, or zoomed so far
out the nodes are confetti — press 1 and the whole picture
snaps back.
Recent versions of the editor also include a command bar, opened with
Ctrl+K, that lets you search for actions, workflows, and
settings by typing instead of hunting through menus — and it doubles as
a way to rediscover a shortcut you have forgotten. The full, current
shortcut list lives in the n8n documentation and drifts slightly between
versions, so treat the tables in this chapter as the stable core rather
than an exhaustive inventory.
Every workflow begins with a trigger node — the step that decides when the workflow runs (Chapter 7's territory). Everything after it is the action chain, and there are three ways to grow it.
The nodes panel. Click the + button at
the edge of the canvas, or press N, to open the nodes panel
— a searchable list of every node your instance knows about: core nodes,
integration nodes for third-party apps, and any community nodes you have
installed (Chapter 15). Type a few letters of what you want ("sheet",
"slack", "http") and the panel filters as you type. Click an entry to
see its available actions, then click an action to drop the node onto
the canvas. (Older editors opened this panel with Tab, and
you will still see Tab in many tutorials and even n8n's own
posts; if one binding does nothing on your version, try the other. The
+ button always works regardless of version.)
The connector plus. Hover over any node on the
canvas and you will see a small + at its output — the
right-hand edge, where data leaves. Click it and the nodes panel opens
again, but this time the new node arrives pre-wired to the one you
started from. This is the fastest way to build a linear chain, because
it does the adding and the connecting in one gesture.
Drag from a connector. Click and hold on a node's output connector, drag the resulting line to an empty patch of canvas, and release. The nodes panel opens, and whatever you pick lands there, already connected. Drag the line onto another existing node's input instead, and you simply wire the two together.
Connections themselves deserve a moment. Data in n8n flows left to
right: out of a node's output connector, along the line, into the next
node's input connector. To remove a connection, hover
over the line until controls appear and click the delete control. To
insert a node into the middle of an existing
connection, hover over the line and use the + that appears
on it — the new node splices in, and the connection re-routes through it
automatically. That splice move is one of the most useful gestures in
the editor: it means you can retrofit a filter or a transformation into
a working chain without rewiring anything by hand.
Rearranging is plain dragging. Grab a node by its body and move it wherever you like; connections stretch and follow. Layout is purely cosmetic — n8n executes based on connections, not positions — but tidy layout is documentation, and messy layout is technical debt you can see. Recent versions include a tidy-up control on the canvas that auto-arranges nodes into a clean left-to-right flow; use it when a workflow has grown shaggy, then adjust by hand.
To select several nodes at once, drag a box around them on empty
canvas, or hold Shift and click nodes to add them to the
selection one at a time. Ctrl+A selects everything. A
multi-selection moves, copies, and deletes as a unit.
These four habits separate maintainable workflows from archaeology sites.
Every node gets a default name — "Google Sheets", "Slack", "HTTP
Request" — and the second node of the same type gets a numbered suffix.
Rename them to say what they do: "Add row to tracking sheet",
"Notify team in chat". Select the node and press F2, or use
the node's context menu (right-click), type the new name, and confirm.
Renaming matters more than it looks: node names appear in execution logs
(Chapter 21), in error messages, and inside expressions that reference
other nodes' output (Chapter 17). A workflow whose log reads "Inquiry
submitted → Add row to tracking sheet → Notify team in chat" debugs
itself.
Watch out: Expressions can reference nodes by name — "give me the value that came out of the node called X." Modern versions of the editor update those references for you when you rename a node in place, but the safety net is not absolute: expressions typed in unusual ways, or workflows pasted in from elsewhere, can slip through. After renaming a node in a workflow that already has expressions, skim the downstream nodes for red error text before moving on. The cheapest time to settle on good names is before you write expressions at all.
Select a node and press D (or use the context menu) to
deactivate it — commonly called disabling. A disabled node is
skipped at execution time: for an ordinary node in a linear chain, data
passes straight through it unchanged, as if the node were a piece of
wire. The node grays out on the canvas so the state is visible at a
glance.
Disabling is your scalpel for experiments. Want to test the chain without actually sending the chat message? Disable the chat node and run. Suspect a transformation step is mangling data? Disable it and compare the output. It is also how you park half-built ideas: add the node, disable it, leave a note, come back later.
Watch out: When a disabled node is skipped, downstream nodes receive the upstream node's data instead of the disabled node's output. If a later step depends on a field the disabled node would have created, that step will fail or misbehave. Disabling is for isolating steps during testing, not for permanently routing around logic — if a node should never run, delete it or redesign the chain (Chapter 9 covers proper branching).
Select one or more nodes and Ctrl+C copies them;
Ctrl+V pastes. Pasted nodes keep their parameters and their
connections to each other, so you can lift a three-node pattern out of
one workflow and drop it into another intact. Ctrl+X cuts.
The context menu also offers a duplicate action for quick same-canvas
copies.
Here is the delightful part: what lands on your clipboard is the workflow's underlying JSON — the text format n8n uses to describe nodes and connections. That means copy and paste works across workflows, across browser tabs, even across different n8n instances. It also means you can paste a workflow snippet into a text file as a backup, or copy JSON someone shared in a forum post or template gallery and paste it directly onto your canvas, where it materializes as real nodes.
Watch out: Because copied nodes are plain text, everything typed into their parameters travels with them — API URLs, email addresses, spreadsheet IDs, any secrets you unwisely pasted into a parameter field. Credentials themselves are not included (they are stored separately and referenced by name — Chapter 11), but parameter values are. Skim before you share workflow JSON publicly, and never put a raw secret in a parameter field when a credential can hold it instead.
Ctrl+Z undoes; Ctrl+Shift+Z redoes. Undo
covers canvas-level operations — adding, deleting, moving, connecting,
disconnecting — and edits generally, but its history lives in your
current editor session. It is a safety net for the last few minutes, not
a version history. For real versioning — restoring last Tuesday's
workflow — you want saved versions and source control, covered in
Chapters 10 and 35.
You do not need to memorize every binding. These are the ones that pay rent daily:
| Shortcut | What it does |
|---|---|
Ctrl+S |
Save the workflow |
Ctrl+Z / Ctrl+Shift+Z |
Undo / redo |
N (older editors: Tab) |
Open the nodes panel |
Ctrl+Enter |
Execute the workflow manually |
Enter (node selected) |
Open the node's detail view |
F2 |
Rename the selected node |
D |
Disable / re-enable the selected node |
Delete |
Delete the selected node(s) |
Ctrl+C / Ctrl+X / Ctrl+V |
Copy / cut / paste nodes |
Ctrl+A |
Select all nodes |
Shift+S |
Add a sticky note |
0 / 1 |
Reset zoom / zoom to fit the workflow |
Ctrl+K |
Open the command bar |
Arrow keys move your selection from node to node, which combined with
Enter gives you an entirely mouse-free way to walk a chain
and inspect each step.
n8n gives you two documentation tools, and the workflows you will still understand next year use both.
Sticky notes are colored rectangles that float on
the canvas. Press Shift+S (or find Sticky Note in the nodes
panel) to add one, double-click it to edit, and click away or press
Esc to finish. They support Markdown — headings, bold,
lists, links — so a sticky can be a one-line label or a small README.
Drag its edges to resize, and use its context menu to change its
color.
The power move is using a large sticky as a background region: stretch it behind a group of related nodes so the group reads as a titled block — "1. Receive and record the inquiry", "2. Notify and acknowledge". Color the regions consistently across your workflows and the canvas becomes self-narrating. Almost every polished template in the public gallery does exactly this, which is why they are readable at a glance.
Node notes live on individual nodes. Open a node,
switch to its Settings tab, and you will find a
Notes field, plus a toggle to display the note on the
canvas beneath the node's name. This is the place for the sentence that
saves an hour: "Column names must match the sheet header row exactly —
including the capital I in Inquiry."
Tip: Write the sticky notes while you build, not after. The thirty seconds it takes to label a region is the same thirty seconds future-you would spend re-deriving what the region does — except you only pay it once, and you pay it while the answer is still in your head.
Double-click any node (or select it and press Enter) and
the editor opens the node detail view — the focused editing
screen where you will spend most of your building time. It has three
vertical panes:
The center pane carries a button — labeled Test step or
Execute step depending on your version — that runs just
this node, using the input shown on the left. This single-node
execution loop is the heartbeat of building in n8n: configure, test the
step, inspect the output, adjust, test again. You never have to run the
whole workflow just to check one node's behavior, though Chapter 10
covers when and how to do full test runs.
The center pane has two tabs, and the distinction is worth stating plainly:
Parameters is the what:
everything specific to this node's job. Which spreadsheet, which
channel, what message, which fields. Every node type has different
parameters.Settings is the how: behavior
controls that nearly every node shares. This is where you find the
Notes field just mentioned, along with options such as
retrying automatically when the node fails, choosing what happens on
error (stop the workflow, or continue), executing the node only once
regardless of how many items arrive, and forcing the node to always
produce output. Leave these at their defaults for now — they belong to
the error-handling and reliability story told in Chapters 23 and 24, and
flipping them without understanding them is a classic source of
mysterious behavior.For this chapter, live in Parameters and visit
Settings only for the notes field.
Both data panes can render their items in three views, switchable at the top of each pane:
| View | What it shows | When to use it |
|---|---|---|
Table |
Items as spreadsheet-style rows, fields as columns | Scanning many items quickly; sanity-checking values |
JSON |
The raw structured text of each item | Seeing nesting, exact types, and precisely what an expression will receive |
Schema |
The field names and structure, collapsed, without the noise of values | Understanding what fields exist; the launchpad for drag-to-map |
JSON — JavaScript Object Notation — is the structured text format n8n
uses for all item data; Chapter 16 teaches you to read it fluently, and
you saw its shape in Chapter 3. You do not need fluency yet. The
practical rhythm is: Table to eyeball results,
Schema to find a field you want to use, JSON
when something looks wrong and you need ground truth. When a node
handles files rather than structured data, a binary view appears as well
— that story belongs to Chapter 20.
The output pane also offers data pinning — freezing a node's output so subsequent test runs reuse it instead of calling the real service again. It is a debugging and test-economy tool, covered properly in Chapters 10 and 22; for now, just recognize the pin icon so you do not press it by accident and wonder why your data stopped changing.
Open almost any integration node — the nodes that talk to specific
products like Google Sheets, Slack, Notion, HubSpot, Airtable — and the
top of the Parameters tab follows the same two-question
pattern:
A messaging product might expose resources like Message and Channel, with operations like Send, Update, and Delete on a message. A spreadsheet product might expose Document and Sheet, with operations like Append Row, Get Rows, Update Row. A CRM might expose Contact, Deal, and Company, each with Create, Get, Get Many, Update, Delete.
Once you have internalized this grammar, every unfamiliar node in the catalog becomes half-familiar: your first two clicks are always "which resource?" then "which operation?", and only then does the node reveal the parameters specific to that combination. This is also exactly how the nodes panel organizes things — searching for an app shows you its available actions, which are resource-operation pairs with friendly names. Chapter 12 (Navigating and Operating the Integration Catalog) builds on this pattern across the whole catalog.
Two conventions to know. First, operations named Get Many (sometimes "Get All" in older nodes) return multiple items and usually offer a limit control and filters — remember from Chapter 3 that n8n nodes naturally emit lists of items, and downstream nodes run once per item. Second, many parameter fields for choosing a resource offer a From list / By ID / By URL style selector: "From list" uses your credential to fetch real choices from the connected account (pick your actual spreadsheet from a dropdown), while the ID or URL modes let you paste an identifier directly or compute one with an expression. Use the list mode while learning — it eliminates a whole category of typo bugs.
Below resource and operation, parameters come in a few standard
shapes: free-text fields, dropdowns, toggles, and collapsible sections
usually labeled Options or Additional Fields
that hold the optional, less common settings. Required fields are marked
and will complain if left empty. Anything you type is a fixed
value — the same every run. The alternative is an expression, which
brings us to the most satisfying gesture in the editor.
An expression is a small formula, wrapped in double curly braces, that computes a parameter's value at runtime from incoming data — "put the sender's email here", where here changes with every item. Chapter 17 teaches the expression language in full. What you need today is the shortcut that writes expressions for you:
Drag a field from the input pane and drop it into a parameter field.
Open a node's detail view, switch the input pane to
Schema view, find the field you want — say
email — and drag it into, for example, a message-text
parameter. Two things happen: the parameter flips from
Fixed to Expression mode (most parameters
carry a small toggle between the two), and n8n writes the correct
expression referencing that field, curly braces and all. Drop several
fields into one text parameter, type ordinary words around them, and you
have a template: "New inquiry: name from company"
where the italicized parts are dragged-in fields.
While you build, the expression editor previews the result using the first input item, so you see immediately whether you grabbed the right field. If the input pane is empty — because the upstream node has not run yet — there is nothing to drag; run the previous step first so real data is available. This is why building in n8n naturally alternates between configuring and test-running: each executed step furnishes the raw material for mapping the next.
Tip: Always prefer dragging over typing expressions by hand at this stage. The drag gesture cannot misspell a field name, and it handles nested structures correctly. When Chapter 17 teaches you to write expressions manually, you will find that reading the ones the editor generated is the best tutorial you could ask for.
The moment you configure an integration node, it asks for a credential — the saved, encrypted bundle of authentication details (an API key, an OAuth connection, a username and password) that proves to the external service you are allowed in. Inside the node, a credential parameter near the top lets you pick an existing credential from a dropdown or create a new one.
For this chapter, assume the credentials you need already exist — created by you following a node's guided setup, or shared with you by a teammate — and treat them as exactly what the dropdown suggests: a named thing you select. Two facts complete the black-box view. Credentials are stored once, centrally, and referenced by nodes — ten Slack nodes can share one Slack credential, and updating it updates all ten. And credentials never travel with copied workflow JSON — paste a workflow into another instance and each integration node will ask you to select or create credentials there. Everything else — creating credentials from zero, OAuth versus API keys, sharing and scoping them — is Chapter 11's territory.
Time to assemble the deliverable. The napkin spec from Chapter 6's worked exercise, reduced to its skeleton, reads: when a visitor submits the website contact form, record the inquiry in the tracking sheet, tell the team in chat, and send the inquirer an acknowledgment. The full spec also tidies the incoming data, looks up whether the contact already exists, and filters out vendor pitches — and we are deliberately not building those parts yet. The lookup and the filter are decisions, which makes them flow control (Chapter 9's territory), and the tidying is expression work (Chapters 17 and 18 sharpen it). What you build here is the linear trunk those chapters graft onto: trigger, record, notify, acknowledge. If your own plan involves different apps, follow along anyway and substitute — every mechanic below is app-agnostic.
From the workflows list, choose Create Workflow. Click
the placeholder name and rename it "Website inquiry intake". Save with
Ctrl+S.
Chapter 7's decision path, applied to the spec's trigger sentence ("a visitor submits the contact form on the website"), offers three doors: the form product's own event trigger, if the site's form lives in an app the catalog covers; a Webhook node that the existing website form posts to (Chapter 14's deep territory); or the n8n Form Trigger, where n8n hosts the form itself. We build with the Form Trigger, for reasons that are part pedagogy and part honest engineering: it needs no credential and no external setup, so nothing stands between you and working data, and it hands the chain exactly the fields the spec names. If the consultancy later keeps its existing website form instead, the front door changes but the chain behind it does not — swapping triggers on a built workflow is an ordinary, cheap edit so long as the replacement delivers the same field names.
Click the add-first-step prompt (or press N) and search
"form". Select the n8n Form Trigger — its action reads as starting when
a form is submitted. In Parameters, give the form a
visitor-facing title ("Contact us") and add four fields to match the
spec: Name, Email (use the email field type — it validates addresses for
free), Company, and Message (a multi-line text type). Rename the node
with F2: "Inquiry submitted". Save.
Now furnish the chain with real data. Run the node with
Test step: the editor serves your form at a temporary test
address and waits — current versions open the form in a new tab for you,
and if yours does not, the node displays the test link to click. Fill it
in as if you were a plausible prospect, and put your own email
address in the Email field; that small choice pays off in step 5.
Submit, return to the editor, and the output pane now holds one item
whose fields are exactly your form fields. This is the test-URL rite of
passage from Chapter 7 — and the raw material for every mapping that
follows.
Click the + on the trigger's output connector and search
for your spreadsheet app — Google Sheets in our build. In
resource-and-operation terms, you want the sheet resource with the
append-row operation.
Inside the detail view, top to bottom:
Schema view and drag Name, Email, Company, and Message into
their columns. (An automatic mode that matches fields to columns by name
exists too; map manually your first time, because it makes you see every
assignment you are making.)Press Test step, then check the actual spreadsheet: one
new row, containing your test inquiry. This is drag-to-map's quiet
payoff — four mappings, zero typing, zero typos. Rename the node "Add
row to tracking sheet". Save.
Click the + on the output of "Add row to tracking sheet"
and search for your chat app — Slack in our build. Choose the
send-message action: resource Message, operation Send.
Configure top to bottom: select the existing chat credential; choose where the message goes — and while building, pick a private test channel from the list mode, not the real sales channel. Then build the message text with the drag gesture: type a little framing and drag fields into it —
New inquiry: Name (Email) — Company, with the Message on its own line below
— where each bolded piece is a field dragged from the input pane,
landing as a curly-brace expression. Watch the preview render your test
submission's values as you assemble it. Press Test step and
check the channel. Rename the node "Notify team in chat". Save.
A brief item-model checkpoint (Chapter 3; in depth in Chapter 16): nodes run once per item, and a form submission starts its execution with exactly one item — so this run appends one row, sends one message, and will send one acknowledgment. A chain that begins with a Get Many read starts with many items, and this same wiring would then fan out once per item. Keep that distinction in your head permanently; it is the difference between one chat message and forty.
Click + once more and add the email node for whichever
mailbox your credential belongs to — a Gmail or Outlook node, or the
generic email-sending node that works with any mailbox. Resource
Message, operation Send.
Select the credential, then build the message. For the To parameter,
switch the input pane to Schema view and drag the
Email field in. Here is where the earlier choice pays
off: because your test submission used your own address, the
acknowledgment will land in your inbox, not a stranger's. Give the
Subject a fixed value ("We got your message — thank you"), and compose a
short body that drags in Name and, if you like, echoes
the Message back. Press Test step and
check your inbox. Rename the node "Send acknowledgment". Save.
Watch out: Two of the nodes in this chain message real people, which makes the blast-radius question — who could this run touch? — part of build hygiene, not just deployment hygiene. The pattern you just used is the general one: while building, only feed the chain data that points at yourself (your address in the test submission, a test channel in the chat node), so a slip costs nothing. Chapter 10 turns this instinct into a testing discipline, and Chapter 24 into production-grade guardrails.
Back on the canvas, run the full workflow with
Ctrl+Enter or the execute button at the bottom of the
canvas (labeled Execute workflow or
Test workflow depending on your version). With a Form
Trigger at the front, a full run behaves exactly as Chapter 7 described:
the editor waits, listening at the test form address. Open the form,
submit a fresh inquiry, and watch the execution animate left to right —
each node shows a spinner, then a success indicator with the count of
items it produced. Then confirm the napkin spec's outcome sentence,
minus the deferred parts: row in the sheet, message in the channel,
acknowledgment in the inbox. Click any node afterward to inspect exactly
what flowed through it — this per-node inspectability is the debugging
superpower you will lean on constantly (Chapter 22).
Finish with documentation while the build is fresh:
Shift+S for a sticky note behind the whole chain — "Inquiry
intake: form → tracking sheet + team chat + acknowledgment. Duplicate
lookup and vendor-pitch filter arrive next. Owner: you." — and a node
note on the spreadsheet step recording anything non-obvious about the
sheet's columns.
What you deliberately did not do is activate the workflow, so its production form URL is not yet live and no real visitor can reach the chain. Activation — flipping the switch that lets the trigger fire on its own, plus the testing discipline that should precede it — is exactly where Chapter 10 (Test, Fix, Activate, and Keep It Tidy) picks up. And the linear chain you just built is the trunk onto which Chapter 9 grafts the spec's remaining intelligence: the duplicate lookup, the vendor-pitch branch, and the looping and waiting patterns beyond them.
Everything in this chapter compounds. Adding via the connector
+ keeps chains wired correctly by construction. Renaming as
you go makes logs and expressions legible. Disabling isolates suspects.
Copy-paste moves proven patterns between workflows as portable JSON. The
three-pane detail view turns every node into its own laboratory: input
on the left, configuration in the middle, evidence on the right.
Resource-and-operation makes hundreds of integration nodes feel like one
node with different vocabularies. And drag-to-map writes your first
hundred expressions for you, correctly, before you ever learn the
language they are written in.
You now build faster than you can plan — which is precisely the right problem to have walking into the rest of Volume B.
A workflow that runs in a straight line is a conveyor belt: everything that comes in goes through the same stations and comes out the other end. Real processes are not like that. A lead worth chasing gets different treatment than a lead worth ignoring. A refund over a certain amount needs a human sign-off. A thousand records need to be sent to an API in polite chunks rather than one avalanche. This chapter is about the nodes that turn a straight line into a process with decisions in it: If, Switch, and Filter for routing; Merge for bringing paths back together; Loop Over Items for working in batches; Wait for pausing until time passes or a human acts; and the Execute Sub-workflow pair for splitting one big automation into reusable pieces.
Everything here builds on two ideas from earlier chapters. From Chapter 3 (The Core Mental Model), remember that data moves through a workflow as items — individual records, like rows in a spreadsheet — and that most nodes automatically do their work once per item. From Chapter 8 (Building the Action Chain), you already know how to add nodes and drag connections on the canvas. Flow control is just connections with opinions.
The If node asks a yes/no question about each item and routes it accordingly. It has one input and two outputs, labeled true and false. Items that satisfy the condition leave through the true output; everything else leaves through false.
true
+----------------> [Notify sales rep]
[Trigger] --> [If] --+
+----------------> [Add to nurture list]
falseThe crucial mental shift: the If node does not pick one path for the
whole run. It evaluates each item separately. If ten leads
arrive and six have a score above your threshold, six items go down the
true branch and four go down the false branch — in the same execution.
Both branches run. If you come from programming, this is closer to
partitioning a list than to an if statement.
You build the question in the node's condition editor. Each condition has three parts: a value to inspect (usually an expression that pulls a field from the item, written in the double-curly-brace language covered in Chapter 17), an operator (equals, contains, greater than, is empty, and so on), and a comparison value. Operators are grouped by data type — string, number, date and time, boolean, array, object — so pick the type that matches your data before hunting for the operator. You can stack multiple conditions and combine them with AND (all must be true) or OR (any may be true), and the node's options let you relax case sensitivity or type strictness when your incoming data is messy.
Tip: When a condition misbehaves, the culprit is usually a type mismatch — the string
"50"is not the number50. Open the input panel, check what the field actually contains, and either fix the type upstream or enable the node's less-strict validation option. Chapter 16 (Reading and Reasoning About Data) covers this diagnosis in depth.
When a decision has more than two outcomes — route support tickets to billing, technical, or sales queues, say — chaining If nodes gets ugly fast. The Switch node gives you as many outputs as you need.
"billing" --> [Billing queue]
"technical" --> [Tech queue]
[Trigger] --> [Switch] --
"sales" --> [Sales queue]
(fallback) --> [Triage inbox]Switch has two ways of working. In Rules mode, you define a list of routing rules, each with its own conditions (the same condition editor as If) and its own output; each rule adds an output to the node on the canvas, and you can rename outputs so the canvas reads like documentation. In Expression mode, you write a single expression that returns the number of the output each item should take — compact and powerful once you are comfortable with expressions, but harder for a teammate to skim.
Two options matter in practice. A fallback output catches items that match no rule — without it, unmatched items are simply discarded, which is a common source of "where did my ticket go?" mysteries. And an option to send items to all matching outputs changes the default first-match-wins behavior into route-everywhere-it-fits, useful when categories genuinely overlap.
One more branching move needs no special node at all: you can drag connections from a single output to several downstream nodes. Every connected node receives a full copy of the items. This is how you do "log it and email it and update the CRM" — no condition, just three connections from the same output. Keep in mind that these branches still run one at a time within the execution, not simultaneously; more on ordering below.
Sometimes the answer to "what should happen to the items that don't qualify?" is simply "nothing." The Filter node is an If node with the false output sawn off: one input, one output, and the same condition editor. Items that match pass through; items that don't are dropped from the rest of the run.
[Trigger] --> [Filter: has an email address?] --> [Continue with matching items]
|
x non-matching items go nowhereDropped items are not errored, retried, or queued — they are just absent from everything downstream. They remain visible in the execution log (Chapter 21) on the Filter node's input side, so you can always audit what was removed and why.
Choosing between the three routing nodes comes down to what should happen to non-matching items:
| Node | Outputs | Non-matching items | Typical use |
|---|---|---|---|
| If | 2 (true / false) | Continue down the false branch | Two genuinely different treatments |
| Switch | As many as you define, plus optional fallback | Discarded, unless a fallback output exists | Three or more routes |
| Filter | 1 | Dropped from the run | Qualify or ignore; no "else" logic |
Tip: If you find yourself adding an If node and leaving its false output unconnected, replace it with a Filter. The workflow behaves identically, and the canvas now says what you mean.
What actually happens to a branch that receives no items? Nothing — and that is by design. If every incoming lead scores high, the false branch of your If node gets zero items, its downstream nodes never execute, and the editor shows them as untouched in that run. This is normal, not an error. An execution finishes when every branch that received items has run to completion; empty branches are simply skipped.
This matters for how you read execution history. A node that "didn't run" in a given execution usually means no items reached it, not that something broke. Chapter 22 (The Debugging Craft) leans on this distinction constantly.
n8n runs one branch at a time. When a node has multiple outputs with items on them — or one output fanned out to several nodes — the engine completes one branch fully before starting the next. In current versions, the order among sibling branches follows their position on the canvas: the branch whose first node sits higher runs first, and the leftmost wins a tie. (Workflows built on much older versions may use a legacy ordering; the workflow's settings dialog, opened from the editor's overflow menu, has an execution-order setting if you need to check.)
Watch out: Never encode business logic in branch ordering. "The top branch writes the record, so by the time the bottom branch reads it, it exists" works right up until someone nudges a node on the canvas. If step B depends on step A's result, connect B after A, or rejoin the branches with Merge so the dependency is explicit in the graph.
Branches often need to come back together: two enrichment paths that should feed one final step, or a true/false split where both outcomes end with the same "log the result" action. The Merge node has multiple inputs and one output, and it exists to turn parallel paths back into a single stream.
+--> [Path A: enrich from CRM] -----+
[If] ---------+ +--> [Merge] --> [Log outcome]
+--> [Path B: enrich by lookup] ----+For flow-control purposes, the mode you want most often is the simplest: append, which passes along every item from every input as one combined stream. The Merge node also has genuinely powerful data-joining modes — matching items across inputs by a shared field, pairing by position, even SQL-style joins — but those are data-shaping tools, and they live in Chapter 18 (The Transformation Toolkit). Here, think of Merge as the diamond that closes a fork.
One behavior to understand: Merge waits. It runs only after every connected input has been resolved — in the normal case, a branch that delivered zero items counts as resolved-and-empty, and the merge fires with whatever the other branches supplied. If a downstream chain seems to stall or produce a surprising shape, click through the Merge node's input panels in the execution view and check what each branch actually delivered; when in doubt, test with representative data pinned to the trigger (Chapter 10 covers pinning).
Watch out: The classic Merge failure is an empty branch that reads to the engine as "this input never ran" — the merge stalls, or fires with less than you expected. The well-worn insurance policy: on the last node of each branch feeding the Merge, open the node's
Settingstab and enableAlways Output Data, so even an empty result delivers an item and the merge proceeds. Reach for this the moment a Merge misbehaves around an If or Filter that can legitimately produce nothing.
The No Operation node (listed in the nodes panel as "No Operation, do nothing") does exactly what it says: items pass through unchanged. It sounds useless and is quietly valuable. Use it to give a branch an explicit, labeled endpoint — an If node whose false branch ends in a NoOp named "Ignored: score too low" documents itself, where a dangling unconnected output leaves the next reader guessing whether the branch was finished or forgotten. It also serves as a placeholder while you design ("something will go here") and as a clean junction point when several branches converge on the same next step.
Here is the thing newcomers from programming backgrounds need to unlearn: in n8n, you almost never write a loop to "do this for each record." Per-item execution is the loop. If a hundred items reach a Send Email node, a hundred emails go out — one node, no loop, no counter. Chapter 3 introduced this and Chapter 16 works through the consequences; internalize it before reaching for a loop node, because the most common looping mistake is building machinery n8n already provides.
Explicit loops earn their place in a few specific situations:
The loop node is called Loop Over Items (its older name, Split in Batches, still appears in docs and forums — same node). It takes the incoming items, holds them, and releases them in batches of the size you set. It has two labeled outputs: loop, which emits the current batch, and done, which fires after the final batch has been processed.
The wiring is the part that trips people up. You connect the processing chain to the loop output, and then connect the end of that chain back into the Loop Over Items node's input. Each time the loop-back connection delivers results, the node emits the next batch; when no batches remain, the done output fires and the workflow continues, carrying the items that flowed back through the node during the loop — your accumulated results.
loop
+----------> [Process one batch] --+
| |
[Trigger] --> [Loop Over Items] <--------------------+
|
+----------> [Continue with all results]
doneWatch out: The number-one loop bug is forgetting the loop-back connection. Without it, the node emits the first batch, the chain processes it, and the execution ends — the second batch never arrives and the done branch never fires. If your loop "only ran once," check the wiring before anything else. The number-two bug is connecting the wrong thing back and creating a loop that never exhausts; watch your first test run closely and be ready to stop it.
The node also has a reset option that makes it forget its position and start over — an advanced tool for nested or multi-pass patterns, and a way to build an accidental infinite loop if you enable it without understanding it. Leave it alone until you have a run that specifically needs it.
Workflows do not have to finish in one breath. The Wait node pauses an execution at a specific point and resumes it later — seconds later, days later, or whenever an external signal arrives. Short pauses are held in memory; for longer ones, n8n saves the execution's state, releases the resources, and loads everything back when it is time to continue. From your perspective the workflow simply picks up at the next node with all its data intact; in the executions list (Chapter 21), the run shows as waiting in the meantime.
The Wait node has four resume modes:
| Resume mode | Execution resumes when... | Typical use |
|---|---|---|
| After time interval | A duration you set has elapsed | Cool-downs, polite delays, "follow up in 3 days" |
| At specified time | A specific date and time arrives | "Send the reminder Monday 9am", scheduled follow-through |
| On webhook call | An HTTP request hits the execution's unique resume URL | Approval links, callbacks from external systems |
| On form submitted | Someone submits the execution's generated n8n form | Structured human input mid-flow |
The first two modes are self-explanatory clocks. The last two are where the Wait node becomes a doorway for humans and external systems, and they revolve around resume URLs. A webhook, covered fully in Chapter 14, is simply a URL that an outside system calls to hand data to your workflow. When an execution reaches a Wait node in webhook mode, n8n mints a resume URL unique to that execution; an HTTP request to it wakes that specific run. In form mode, the URL serves a web form (built with the same form-building blocks as n8n's form trigger), and submitting it resumes the run with the answers as data.
You access these URLs through expressions —
$execution.resumeUrl for webhook mode and
$execution.resumeFormUrl for form mode — and here is the
sequencing subtlety: you must send the URL somewhere before the
execution pauses. The node that emails or messages the link goes
before the Wait node, using the expression to embed the
URL; the values resolve correctly even though the Wait node hasn't run
yet.
Watch out: Resume URLs are per-execution. Do not copy one out of a test run and hardcode it into an email template — it will resume that old test execution (or nothing at all), not the current run. Always embed the expression so each execution mails out its own key, and make sure the node that sends the URL runs in the same execution as the Wait node — a partial test run that starts mid-workflow mints a different URL.
For the webhook and form modes, enable the option to limit the wait time so the execution eventually resumes on its own if nobody acts. Without it, an ignored approval email means an execution waiting indefinitely.
The approval gate is the flagship Wait pattern: the workflow prepares something, a human says yes or no, the workflow acts accordingly.
[Trigger] --> [Draft the refund] --> [Email approver ] --> [Wait: on webhook call]
[ links use resumeUrl ] |
[ ?decision=approve / deny] approver clicks a link
|
v
[If decision = approve]
true | | false
v v
[Issue refund] [Notify requester]Three ways to build it, in increasing order of structure:
Approval links. Before the Wait node, send a message
containing two links — both pointing at
$execution.resumeUrl, one with
?decision=approve appended and one with
?decision=deny. When the approver clicks, the request's
query parameters arrive as the Wait node's output data; an If node reads
the decision and branches. It is crude (anyone with the link can click
it, and a link preview bot can trigger it) but takes five minutes to
build. Chapter 14 (Webhooks In Depth) covers query data, response
behavior, and locking webhooks down.
A resume form. Switch the Wait node to form mode and
send $execution.resumeFormUrl instead. The approver lands
on a proper form — dropdown for the decision, text box for a reason —
and the submission becomes structured data in the workflow. Better audit
trail, better for non-binary decisions.
Built-in send-and-wait operations. Several messaging and email app nodes (Slack and Gmail among them) offer a "send and wait for response" style operation that bundles the message, the wait, and approval buttons or a form into a single node. When your approver lives in one of those tools, this is the cleanest option — check the node's operation list for it. Chapter 37 (The Support Copilot) uses this pattern as the safety valve on an AI agent.
Tip: A production approval gate needs three exits, not one: approved, rejected, and nobody answered. Set the wait-time limit, and route the timeout to a reminder or an escalation. The workflows that age best assume humans are busy.
As workflows grow, the canvas stops being the readable map it was at ten nodes. The remedy is the same one programming discovered decades ago: break the big thing into named, reusable pieces. In n8n, a sub-workflow is an ordinary workflow that another workflow calls like a function.
Two nodes make the pattern work, one on each side:
Parent: [Trigger] --> [Prepare order data] --> [Execute Sub-workflow] --> [Send receipt]
| ^
items in items back
v |
Child: [Execute Sub-workflow Trigger] --> [Validate] --> ... --> [Edit Fields: shape the return]You point the Execute Sub-workflow node at the child — most commonly by choosing a workflow from the same instance, though the node supports other sources such as defining the workflow inline. The parent's incoming items are handed to the child's trigger.
On the child side, the trigger decides what it accepts. It can accept
whatever arrives, or — better — declare specific input fields,
optionally illustrated with a JSON example. Declared fields turn the
sub-workflow into a contract: any parent can call it as long as it
supplies email, amount, and
order_id, and the child's editor shows exactly what it
expects. For any sub-workflow more than one parent will call, declare
the inputs.
A calling detail worth knowing: an option on the Execute Sub-workflow node controls whether the child runs once with all items or once per item. The default single-call-with-everything is usually what you want; per-item calls make sense when each item is a genuinely independent job.
By default the parent waits, and what comes back is the output of the last node that ran in the child. This is the sharpest edge in the whole pattern: if the child happens to end on a node that outputs some API's verbose response, that is what the parent receives. End every sub-workflow with a deliberate shaping step — an Edit Fields (Set) node that constructs exactly the return payload you intend. Treat it as the sub-workflow's return statement.
You can also switch off waiting, making the call fire-and-forget: the parent hands over the items and moves on immediately. Use it for side quests — logging, notifications — where the parent needs no answer.
Two operational notes. Sub-workflows do not need to be active to be called — activation (Chapter 10) is about triggers listening for outside events, and a sub-workflow's trigger listens only for its parents. And each sub-workflow call is recorded as its own execution in the executions list, linked from the parent's run, which keeps the audit trail intact across the boundary (Chapter 21).
Split when at least one of these is true:
And resist splitting when none of them are: single-use logic scattered across five thin sub-workflows is harder to follow than one honest canvas, and every boundary adds a data hand-off you must keep shaped and versioned. Extract when a seam earns its keep, not preemptively.
Error workflows — a special workflow that runs whenever another workflow fails — are a cousin of this pattern, wired through their own trigger; they belong to Chapter 23 alongside error branches and retries.
Flow control is a small vocabulary that composes into almost any process: If and Switch to route, Filter to qualify, Merge to rejoin, Loop Over Items when batching genuinely beats per-item execution, Wait to let time pass or humans decide, and sub-workflows to keep any one canvas honest. When you sketch a new automation, name the shapes first — "split by type, gate the risky path on approval, rejoin, hand fulfillment to a sub-workflow" — and the node layout follows almost mechanically. The worked projects in Chapters 36 and 37 do exactly this at full scale, and Chapter 24 picks up where the loop and Wait shapes meet production reality: pacing, idempotency (designing steps so that an accidental repeat does no harm), and recovering gracefully when the world misbehaves.
Every build session in n8n settles into the same rhythm: run something, look at what came out, fix what is wrong, and run it again. Builders who get fast at this loop ship automations in an afternoon; builders who fight it spend that afternoon re-triggering their whole workflow to test a change in the last node. This chapter is about the loop itself — executing a whole workflow versus a single node, re-running from a midpoint, reading output, and pinning sample data so you are not begging an external system for fresh test events every two minutes. It then covers the unglamorous work that keeps a workflow trustworthy over time: saving, version history, workflow-level settings, and the naming-tags-folders hygiene that stops your workspace from becoming a junk drawer. It ends where every build ends: flipping the workflow to active and confirming that the first real execution actually happened.
A quick vocabulary re-anchor, since this chapter uses all four core terms constantly: a workflow is the automation you draw on the canvas, a node is one step in it, an item is one unit of data flowing between nodes, and an execution is one complete run of the workflow. Chapter 3 (The Core Mental Model: Workflows, Nodes, Items, and Executions) covers these in depth.
While a workflow is open in the editor, nothing runs on its own. Executions happen only when you ask for them — these are called manual executions (n8n also calls them test executions), and they are separate from the production executions that happen after you activate the workflow. Manual executions run immediately, show their results directly on the canvas, and exist precisely so you can watch data move step by step.
You have three ways to run things during a build, and knowing when to use each is most of the craft.
The large execute button at the bottom center of the canvas (labeled
Execute workflow — some versions have labeled it
Test workflow) runs the entire workflow once, from the
trigger onward. What "from the trigger" means depends on the trigger
type, which Chapter 7 (Triggers: Deciding When Work Happens) covers in
detail:
As the run proceeds, each node lights up in turn, and when it finishes, small item-count badges appear on each node showing how many items it produced. Green means the node succeeded; a red indicator means it errored, and clicking the node shows you the error message. This whole-workflow run is your integration test: it proves the chain works end to end.
Watch out: When you execute a workflow whose trigger is a webhook, the editor listens on the test URL, which is different from the production URL the workflow uses once activated. Sending your test request to the production URL while the workflow is inactive does nothing, and this mismatch is one of the most common "why is nothing happening" moments for new builders. Chapter 14 (Webhooks In Depth) explains the two URLs fully.
Running the whole workflow to test one node is wasteful, and sometimes actively harmful — you do not want to re-send a Slack message or re-create a CRM (customer-relationship-management) contact just to check whether the formatting node after it works. So n8n lets you execute one node at a time. Open the node (double-click it) and use its execute button in the node panel, or hover over the node on the canvas and click the small play control. n8n calls this executing a step.
Here is the important mechanic: a node needs input data to run. When you execute a single node, n8n looks at the nodes upstream of it. If they already have output data from a previous run — or pinned data, which we will get to shortly — n8n reuses that data and runs only your node. If the upstream nodes have never produced data in this session, n8n runs them first to generate it. In practice this means the first single-node execution in a session may run a short chain, and every one after that runs just the node you asked for.
This is the tightest loop in the editor and where you will spend most of a build: open a node, tweak a parameter or an expression (a double-curly-brace formula that computes a value from earlier nodes' data — Chapter 17's subject), execute the step, read the output, repeat. Ten-second iterations instead of two-minute ones.
The single-node mechanic generalizes into a genuinely powerful pattern: partial re-runs. Because n8n caches each node's output from the last manual execution, you can change a node in the middle of a workflow and re-run from that point forward without re-triggering anything upstream. Execute the changed node to check it in isolation, or execute the whole workflow again — n8n will reuse pinned upstream data rather than refetching it, so the run effectively starts from your frozen sample (pinning is covered in the next section; without pinned data, a full run re-executes everything).
The everyday shape of a build session looks like this:
There is one more midpoint tool worth knowing exists: from a past execution's detail view, n8n can copy that execution's data back into the editor so you can re-run the workflow against exactly the data that a previous run saw. It does this by pinning the historical data for you. That feature earns its keep when diagnosing production failures, so it lives in Chapter 22 (The Debugging Craft); here it is enough to know that the pinning mechanism you learn in this chapter is the same machinery.
Every node you open shows up to three panels: an input panel on the left (the items arriving from the previous node), the parameters in the middle (the node's configuration), and an output panel on the right (the items the node produced when it last ran). The output panel offers multiple views — a table view that lays fields out in columns, a JSON view that shows the raw structure (JSON, JavaScript Object Notation, is the bracketed text format nearly all web systems use for data), and a schema view that lists the field names and types. Table view is best for scanning many items; JSON view is best when you need to see nesting; schema view is best when you are about to write an expression and need exact field names.
Get in the habit of checking two things after every step execution: the item count (did the node produce the number of items you expected — one, many, or zero?) and the shape of the first item (are the fields named and nested the way the next node assumes?). A surprising majority of build-time bugs are one of those two things. Chapter 16 (Reading and Reasoning About Data: The Item Model in Practice) goes deep on interpreting what you see; Chapter 8 (Building the Action Chain) covers the canvas and node mechanics themselves.
Tip: When a node's output looks wrong, look at its input panel before touching its parameters. Half the time the node did exactly what it was told and the problem arrived from upstream. Walking the input panels backward node by node until the data looks right is the fastest bug-hunting move in the editor.
The single biggest quality-of-life feature in the edit-time loop is data pinning. Pinning freezes a node's current output so that subsequent manual executions reuse the frozen copy instead of running the node again. Pin your trigger's output, and you never again have to send a test webhook request, wait for a form submission, or hit an external API just to iterate on the nodes downstream.
To pin, run the node once so it has output, then click the pin icon in its output panel (you can also select the node on the canvas and use the pin option from its context menu). The node gets a visible pinned marker — n8n tints pinned nodes so you can spot them at a glance — and from then on, every manual execution treats the pinned data as the node's output without executing the node at all.
This has two immediate payoffs. First, speed: downstream iteration no longer waits on external systems. Second, determinism: every run sees the same input, so when a downstream node's behavior changes, you know it was your edit — not a different sample record — that changed it.
Pinning is most valuable on triggers, but you can pin most nodes' output. A common pattern in a long workflow: pin the output of an expensive enrichment node (say, an API lookup that costs money or is rate-limited) so you can iterate freely on the formatting nodes after it.
A few rules govern what you can pin. Only nodes with a single main output can be pinned — a branching node like the If node, which splits items across two outputs, cannot. Pinned data must be reasonably small — it is stored inside the workflow itself, so enormous payloads are rejected or a poor idea. Binary data (files — see Chapter 20, Files and Remembered State) cannot be pinned, only regular JSON items. And because pinned data is saved with the workflow, anyone else who opens the workflow sees and uses the same pins.
Pinned data becomes a genuine testing tool the moment you realize you
can edit it. The output panel offers an edit mode (a
pencil-style Edit Output control) that lets you modify the
JSON directly — and once you save an edit, the data is pinned
automatically. That means you can manufacture any scenario you like:
email field from a pinned lead to check that
your If node (Chapter 9, Flow Control) actually routes incomplete
records down the fallback branch."paid" to
"refunded" to walk the other side of a branch.[] to see
what the workflow does with zero items — the empty case is where
item-based workflows most often misbehave.This is mocking, in the software-testing sense: substituting controlled fake data for a real dependency. You do not need any external tool for it — the pin-and-edit loop is the mock.
Tip: Build a habit of testing three variants of your pinned trigger data before activating anything: the happy path, an item with a missing or empty critical field, and the zero-items case. Five minutes of edited pins catches the majority of the failures that would otherwise become your first three production incidents.
Pinned data affects manual executions only. The moment the workflow runs in production — from a real webhook call, a schedule tick, or any live trigger — n8n ignores every pin and executes every node for real. Pins are a build-time convenience, never a production behavior.
Watch out: Because pins are ignored in production, never use pinned data as a stand-in for logic. If you pinned a lookup node's output because the lookup was flaky, the flakiness is still there in production — you have hidden it from yourself, not fixed it. Unpin everything mentally before you activate: walk the canvas, look at each pinned node, and ask "am I comfortable with this node running for real, with real data, unattended?" Chapter 23 (Error Handling) is the honest answer to flaky nodes; pinning is not.
n8n does not autosave the canvas. The Save button in the
editor's top bar (or the standard keyboard shortcut, Ctrl+S / Cmd+S)
writes your changes; an unsaved-changes indicator in the top bar tells
you when the editor copy has drifted from the stored copy. If you close
the tab with unsaved changes, the browser will usually warn you, but do
not lean on that — save early and often, the same way you would in any
editor. The canvas also supports undo and redo for edit mistakes within
a session.
Saving has one behavior that surprises people exactly once:
if the workflow is active, saving publishes your changes to
production immediately. There is no separate deploy step, no
draft state — the saved workflow is the production workflow. On
a live workflow, that means the safe editing pattern is deliberate: make
your edits, test them with manual executions and pinned data, and only
then save. If the change is risky, consider duplicating the workflow
(... > Duplicate from the editor menu or the workflow
card), rehearsing the change on the inactive copy, and porting it back —
or, on teams, using the source-control integration described in Chapter
35 (The Platform Surface) to stage changes through an environment
flow.
Watch out: Editing an active workflow and pressing save mid-thought ships your half-finished edit to production. If a real event fires in that window, it runs your half-finished logic. For anything beyond a trivial tweak to a live workflow, either deactivate first, rehearse on a duplicate, or make the full edit-test cycle before the save.
Every save creates a version, and n8n keeps a history of them. From the editor you can open the workflow history panel (look for a history or clock control in the editor's top bar) to see past versions with timestamps and who saved them. From there you can preview an old version, restore it as the current one, or clone it into a new workflow so you can compare side by side.
How far back history reaches depends on your plan: every setup keeps at least a short window (on the order of a day), paid plans keep versions for longer, and enterprise-tier editions keep full history. Treat history as a short-range undo for "the workflow worked yesterday and someone changed something" — it is very good at that. For long-range, auditable versioning with branches and reviews, the Git-based source control feature in Chapter 35 is the right tool; for permission boundaries around who can edit what, see Chapter 34 (Access, Security, and Secrets for Teams).
Each workflow carries a small settings sheet that governs how it
executes. Open it from the editor's top-right ... menu
under Settings. Four of these settings matter to almost
every builder; the rest you will meet when you need them.
| Setting | What it controls | Sensible default posture |
|---|---|---|
| Execution order | How multi-branch workflows sequence their branches | Keep the newer ordering (labeled v1) unless maintaining an old workflow built on the legacy one |
| Timezone | What "9:00 AM" means to this workflow's Schedule Trigger and to date expressions | Set it explicitly per workflow if schedules matter; otherwise it inherits the instance default |
| Timeout | Maximum time an execution may run before n8n cancels it | Enable, with a generous ceiling well above normal runtime |
| Error workflow | Which workflow to run automatically when this one fails in production | Point every production workflow at a shared error handler |
Execution order exists because workflows with parallel branches need a rule for which branch runs first. Modern n8n versions default to a newer ordering (shown as "v1") that executes branches in a predictable sequence based on their layout on the canvas; a legacy setting exists so that old workflows built against the earlier behavior keep working. Leave new workflows on the default. The only time to think about this setting is when a branch's side effects must happen before another branch reads them — and Chapter 9 (Flow Control) argues you should make that ordering explicit with connections rather than relying on branch sequencing anyway.
Timezone matters more than it looks. A Schedule Trigger set to "every day at 07:00" fires at 07:00 in the workflow's timezone. If the workflow inherits the instance default and nobody ever set that default, you get n8n's own fallback — which is New York time, not UTC and quite possibly not your local time either — so your "7 AM" report arrives on US Eastern hours. Setting the timezone explicitly on any workflow with a schedule removes the ambiguity. Date-and-time handling in expressions (Chapter 17) also reads this setting.
Timeout is the backstop against runaway executions — a workflow stuck waiting on a hung API call, or looping over vastly more items than you anticipated. When the timeout elapses, n8n cancels the execution and records it as failed. Set it well above the workflow's honest worst case (a nightly batch that normally takes four minutes might get thirty) so it only fires when something is genuinely wrong. Note that hosted plans may impose their own platform-level execution ceilings on top of this setting; see Chapter 31 (Operating n8n Cloud Like an Owner).
Error workflow is a pointer to another workflow — one that starts with an Error Trigger node — which n8n runs automatically whenever this workflow fails in production. It is the difference between failures that page you and failures that rot silently in a list. The full pattern (what the error workflow receives, how to build a good one, retries and error branches besides) is Chapter 23 (Error Handling: Retries, Error Branches, and Error Workflows); the takeaway here is simply that this field exists on the settings sheet, and no production workflow should leave it empty.
The settings sheet also holds the execution-data saving options: whether to store the details of successful production runs, failed runs, and manual runs, and whether to save per-node progress during a run. These control what appears in the executions list you will rely on after activation. The defaults are fine to start; Chapter 21 (Executions: The System of Record) explains the trade-offs — mostly storage versus debuggability — when you want to tune them.
One workflow needs no organization. Ten need a naming convention. Fifty need tags and folders, and by then it is much cheaper to have started early. The overview page — the list of workflows you see when you are not inside the editor — is the surface all of this hygiene serves: its search matches names, and its filters work on tags, folders, and status.
Adopt a name pattern before you need one, and apply it in the editor's title field (click the workflow name in the top bar to rename). A pattern that scales well:
Leads: enrich and route inbound form fills,
Billing: sync Stripe invoices to accounting,
Ops: nightly database backup report. The prefix groups
related workflows alphabetically; the verb phrase says what the workflow
does, not what it touches.Sub: prefix —
Sub: format address block — so nobody activates or deletes
one without realizing other workflows depend on it.WIP: or
Test: prefix on scratch workflows tells your future self —
and teammates — what is safe to ignore or delete.Rename ruthlessly. "My workflow 3 copy" is a small lie you tell your future self, and search cannot rescue a workspace where every name is a variation of the tool it starts with ("Webhook test", "Webhook test 2", "webhook NEW").
Tags are free-form labels you attach to a workflow — click the tag
area next to the workflow's name in the editor to add one or create a
new one — and they exist for exactly one purpose: filtering the overview
list. Tags are shared across the workspace, so a small, deliberate
vocabulary beats an organic sprawl. Three tag families cover most needs:
domain (marketing, finance,
internal-ops), status (production,
wip, deprecated), and mechanism
(sub-workflow, error-handler,
scheduled). A workflow can carry several tags, which is
precisely what makes them better than names alone for cross-cutting
queries — "show me everything tagged production and
finance" is one filter click away.
Prune the tag list occasionally. Tags like new,
misc, temp, and test2 accumulate
like barnacles, and every junk tag makes the useful ones harder to
trust.
Recent n8n versions add folders to the overview page: create one from
the overview's new-item control, then drag workflows in, and nest
folders inside folders where the hierarchy earns it. Folders answer
"where does this live?" while tags answer "what is this like?" — a
workflow lives in exactly one folder but can carry many tags. A
pragmatic structure is one folder per business domain or per client,
with a _Sub-workflows folder alongside them so shared
building blocks are easy to find and hard to delete accidentally.
Folders organize; they do not protect. Anyone who can see the folder can still edit or delete what is inside. When you need actual boundaries — separate teams, separate clients, separate credentials — the answer is projects, n8n's permission containers, which are Chapter 34's territory (Access, Security, and Secrets for Teams).
Two smaller hygiene tools round out the kit.
Duplicate (from the workflow's ... menu)
gives you a safe copy for experiments — better than editing production
in place. And on current versions, archive retires a
workflow without deleting it: archived workflows disappear from the
default overview list but remain recoverable behind a filter. Prefer
archiving to deletion for anything that ever ran in production; the
execution history and the workflow logic are cheap to keep and painful
to reconstruct.
Tip: Do a ten-minute tidy at the end of every build session: real names on anything you created, tags applied, experiments either archived or promoted, and pins removed from nodes where they were only scaffolding. Hygiene done in the moment costs minutes; hygiene done six months later is an archaeology project.
A workflow you have tested is still just a drawing until you activate it. Activation is the moment n8n starts honoring the trigger for real: registering the production webhook URL, starting the schedule clock, or beginning to poll the external service.
The Active toggle sits in the editor's top bar (the
overview list has an equivalent per-workflow switch). Before you flip
it, run the pre-activation walk:
Then flip it. If the toggle is grayed out or refuses, the usual cause is a trigger that cannot be activated — a workflow whose only trigger is the Manual Trigger has nothing to listen for, and a sub-workflow whose only trigger is the Execute Sub-workflow Trigger (the node labeled When Executed by Another Workflow in the editor) runs when its callers invoke it rather than being switched on by this toggle.
Activation changes three things at once. The trigger goes live — webhooks now answer on the production URL rather than the test URL, and schedules begin counting. Executions now happen unattended, whether or not you have the editor open, with their results recorded in the executions list instead of painted on your canvas. And pinned data stops mattering, as covered above.
Do not activate and walk away. An activated workflow that has never handled a real event is a hypothesis, not an automation. Confirm it the same day:
Cause a real event. Submit the actual form, send a real request to the production webhook URL, or create a genuine test record in the source system. For a schedule that fires infrequently, either wait for the tick or temporarily tighten the schedule so it fires a couple of minutes from now, let it fire once, and set it back — remembering that this counts as editing an active workflow, so make the change deliberately and save.
Find the execution. Open the workflow's
Executions tab (the editor has one alongside the canvas;
there is also an instance-wide executions list). Filter to production
executions if the list mixes in your manual test runs. You are looking
for one new entry, timestamped just after your event, with a success
status.
Open it and read it. Click the execution to see the workflow rendered with that run's actual data — the same input and output panels you used at build time, now showing what production really saw. Verify the trigger item looks like the real event, the item counts are right, and the final node did what it claims.
Verify the effect in the destination system. The execution log can say "sent" while the message sits in a spam folder or the record landed in the wrong CRM pipeline. The loop is only closed when you have seen the real-world result with your own eyes.
If the first production execution fails, resist the urge to guess-and-toggle. The execution record contains the failing node, its error, and the exact data that provoked it — reading it methodically is a craft of its own, and Chapter 22 (The Debugging Craft) teaches it. And if the workflow matters enough to activate, it matters enough to fail loudly: assign the error workflow from the settings sheet (Chapter 23) and put basic monitoring around it (Chapter 25, Monitoring, Insights, and Proving Value) before you consider the job done.
One confirmed production execution is the real finish line of the build loop that began in Chapter 6. Everything before it was rehearsal; everything after it — keeping the thing reliable at 3 AM, at ten times the volume, against APIs that go down — is what Volume E is for.