Skip to module content
🧠AI Academy
0/91
Sign in
Module 05 · ~9 min

Orchestration — n8n at Depth

You're not building workflows. You're building skeletons you clone — the difference between selling hours and selling assets.

Reading progress
0/5 · 0%

The big idea

💡Key idea
n8n is where your repeatable, enumerable workflows live — triggers, branches, retries, and (when useful) a single bounded LLM step baked right in. Here's the shift in how you think about your work: you're not building a fresh workflow for each client. You're building one rock-solid skeleton — with error handling, retries, idempotency, logging, and credential hygiene already wired up — and then cloning it. When the next client says 'we need document intake automated,' you open your skeleton, point the credentials at their system, and call it done. That's configuration, not construction. That's how you stop selling hours and start selling assets.
Quick check
1 question · instant feedback
0/1
  1. Global retry-with-backoff is enabled across a workflow. What breaks first?

How to run it

  1. 1 · Error branches on every fallible node
    Default behaviour on error is stop-and-die-silently. Every HTTP/API node gets an error output wired to a handler; every workflow gets a global error workflow that alerts a human with the execution URL.
  2. 2 · Retries with backoff — only on idempotent steps
    Transient failures (429s, timeouts) get retry-with-exponential-backoff. But retrying a non-idempotent step is a duplicate side-effect: retrying 'send invoice email' sends two invoices. Mark every node send-once vs safe-to-retry before enabling retries anywhere.
  3. 3 · Idempotency keys on inbound webhooks
    Providers deliver at-least-once; duplicates will arrive. First node after the trigger: extract an event ID, check a processed-events store (a Supabase table is fine), exit if seen. Verify webhook signatures — an unauthenticated webhook is an open API that runs your workflow.
  4. 4 · Credential hygiene
    Credentials in n8n's credential store, never in node parameters or code nodes; one credential set per environment; least-privilege scopes; a written rotation note per client. Boring, and the first thing a competent security review checks.
  5. 5 · Sub-workflows for anything reused
    'Log this,' 'notify a human,' 'call the MCP with auth' become sub-workflows invoked everywhere. One fix, every caller — and the main canvas stays readable enough to hand to a client.
  6. 6 · Versioning to git
    Export workflow JSON to a repo on every meaningful change. Client asks 'what changed?'; you answer with a diff, not a memory. Environments get promoted via git, not by editing production live.
  7. 7 · Human-in-the-loop gates (spans all six)
    For consequential actions, the workflow pauses (wait node + approval link, or Slack approve/reject) rather than executes. As in §1: the gate is structural — the send node is only reachable through the approval branch.
Quick check
1 question · instant feedback
0/1
  1. A workflow inherited from a prior vendor stopped running in March; nobody noticed until June. Most likely missing practice?

In the field

🔬Worked example
Weekly ads reporting with a review gate: Schedule trigger (Mon 07:00) → sub-workflow mcp-call (auth + get_ad_performance, 7-day window; error branch → error workflow → Slack alert with execution link) → LLM node drafts commentary at a pinned prompt version → wait node: draft posted to Slack with approve/edit/reject → on approve, send to client; on edit, capture the human's changes to a table (reviewer edits are eval signal, future golden cases) → log run summary (cost, latency, approval outcome) to Supabase. Every checklist item visible in one small workflow. Clone, repoint credentials, and it's the next client's deliverable.
🚫When not to reach for it
Code over n8n when logic is algorithmically dense, needs real tests, or sits on a hot path where per-execution pricing or the visual layer's opacity starts to hurt. Zapier-class is simpler, dearer per task, shallower on errors — fine when three nodes and low stakes is the honest scope. Self-hostability alone decides it for data-sensitive clients. And the over-engineering guard runs in reverse too: saying 'a Zap is enough here' in the scoping doc buys credibility you'll spend later.
Quick check
1 question · instant feedback
0/1
  1. Which choice earns credibility rather than losing it?

Pitfalls & takeaways

Failure modes

  • Happy-path canvases. No error branches; the workflow dies silently for weeks. (The #1 inherited-workflow finding.)
  • Retry-everything. Backoff enabled globally; duplicate invoices, posts, and spend follow.
  • Unverified webhooks. Anyone who finds the URL runs your workflow.
  • Credential sprawl. Keys pasted into code nodes, shared across clients, never rotated.
  • The 60-node monolith. No sub-workflows; nobody — including you in three months — can follow it.
  • Prod-only editing. No git export; 'what changed?' is unanswerable; rollback is archaeology.

Durable takeaways

  • You sell skeletons, not workflows. Configure, don't reconstruct.
  • Retries only on idempotent steps — mark every node before enabling.
  • The tool surface is the security boundary; the approval branch is the gate.
  • If it changed and isn't in git, it didn't change.
Quick check
1 question · instant feedback
0/1
  1. Best place to enforce an approval before a send-to-client action?

Do the work

🏋️Prove you learned it

Build the weekly-reporting skeleton against your MCP, with all six checklist items and the approval gate, exported to git. Then prove the error path: kill the MCP mid-run (or fixture a 429) and screenshot the alert arriving with the execution link.

0 chars
📦Artifact to produce
Workflow skeleton repo with the six-item depth checklist baked in.