For revenue teams, n8n is the tool that turns "someone should follow up on that" into "it happened, within minutes, and we have a record." This guide explains how it works, how to choose between cloud and self-hosting, what its AI capabilities are for, the workflows revenue teams build most, and the error-handling basics that separate a demo from a production system.
In short
- What it is: a node-based automation tool for connecting systems and running logic and AI in workflows.
- Building blocks: triggers start workflows; action nodes do the work; core nodes add logic, scheduling and generic API calls; credentials store authentication (Node types).
- Webhooks: let any system start a workflow by sending an HTTP request, with separate test and production URLs (Webhook node).
- Hosting: n8n Cloud (managed) or self-hosted (you run it), each with its own plans or editions.
- AI: an AI Agent node that can choose between connected tools, with optional human approval before sensitive tools run (Human-in-the-loop for tools).
- Error handling: error workflows, the Error Trigger and deliberate failure with Stop and Error (Handle errors gracefully).
- The rule: a green execution is not proof of a business result. Always verify the outcome.
How n8n works
Workflows
A workflow is a connected set of steps on a canvas. Data enters at the start, passes from node to node, and each node can read what earlier nodes produced. One complete run of a workflow is called an execution, and n8n keeps a history of executions you can open to see exactly what data moved through each step.
Nodes
Nodes are the individual components you compose into workflows. n8n's docs split node operations into two types (Node types):
- Triggers start a workflow in response to an event or condition.
- Actions do something: get or send data, change records, call other systems.
It also distinguishes a few families of nodes worth knowing early:
- App nodes connect to a specific service (a CRM, a spreadsheet, a messaging app).
- Core nodes provide general functionality such as logic, scheduling and generic HTTP requests. When a service has no dedicated node, an HTTP request to its API usually fills the gap.
- Cluster nodes are groups that work together: a root node plus sub-nodes that extend it. AI agents are built this way.
- Community nodes are built and published by the community and can be installed separately.
Credentials hold the API keys or OAuth connections nodes use. The docs note they're stored encrypted. Keep secrets in credentials, never pasted into node fields or code.
Triggers you'll use most
| Trigger | What starts the workflow | Revenue example |
|---|---|---|
| Webhook | Another system sends an HTTP request | A form submission or CRM event arrives |
| Schedule | A time or interval | Every morning, find leads with no activity in 48 hours |
| App trigger | An event in a connected app | A new row in a sheet, a new email |
| Chat trigger | A chat message | An internal assistant answers a rep's question |
| Manual | You click run | Testing, one-off backfills |
Webhooks: the front door
Webhooks deserve special attention because they're how most real-time revenue workflows begin. n8n's Webhook node accepts standard HTTP methods and gives you two URLs (Webhook node):
- Test URL: used while building. You listen for a test event and see the incoming data in the editor.
- Production URL: active once the workflow is published. Data doesn't appear in the editor; you inspect runs in the executions list.
It also lets you choose when to respond to the caller: immediately, when the last node finishes, or through a dedicated "Respond to Webhook" node. For lead capture, responding immediately is usually right, so the form never waits on slow steps.
Two practical habits:
- Never point a live system at a test URL. It only listens while you're testing, so leads sent there are lost the rest of the time.
- Change production webhooks carefully. Test the new logic on the test URL with realistic data before switching anything a live form depends on.
n8n Cloud vs self-hosted
n8n's documentation frames this as two decisions: who runs the infrastructure, and which plan or edition you need (Choose how to use n8n).
| n8n Cloud | Self-hosted | |
|---|---|---|
| Setup | No installation | You install and configure it (for example with Docker) |
| Maintenance | Handled by n8n | Your responsibility: updates, backups, security |
| Control | Limited to available options | Full control over the environment |
| Free option | Free trial | Free Community edition |
| Paid options | Several paid plans | Paid editions unlock features such as SSO and environments |
Plans, limits and prices change often, so check n8n's pricing page before you commit.
How to choose, in practice:
- Learning or validating a first use case? Cloud gets you building today.
- Strict data-residency needs, heavy volume, or custom infrastructure? Self-hosting may fit, if someone owns maintenance.
- No one to patch and back up a server? Don't self-host production revenue workflows. An outage in your automation layer is an outage in your follow-up.
A note on licensing
n8n isn't licensed like typical open-source software. Its Sustainable Use License is a fair-code model: the source is available, and you can use, modify and redistribute it for internal business purposes or for non-commercial and personal use. Restrictions include not charging others for hosted access to n8n or white-labeling it; files marked as enterprise are under a separate license (Sustainable Use License). Using n8n to automate your own company's operations, or consulting on how to build workflows, is described as allowed. If you plan to embed n8n in a product you sell, read the license carefully and talk to n8n.
AI in n8n
n8n lets you connect language models from several providers and place them inside workflows. The piece that matters most is the AI Agent node.
It helps to separate two ideas. A chain follows a fixed sequence of AI calls you designed. An agent uses a language model to decide which action to take next and which connected tool to use. In n8n, AI building blocks follow the cluster-node pattern described earlier: a root node extended by sub-nodes (Node types), so an agent is configured with the model, memory and tools attached to it.
When to use a chain, an agent, or no AI at all
- No AI: the logic is known and stable (if the score is A, assign to the branch manager). Plain nodes are cheaper, faster and predictable.
- A single model call or chain: the task is language-shaped but fixed (summarize this call transcript into three fields).
- An agent: the path genuinely depends on the input (a rep asks a question, and the agent decides whether to search the CRM, check a calendar or read a policy doc).
Agents that can act, not just answer, need guardrails. n8n documents a human-in-the-loop pattern in which the workflow pauses and sends an approval request (for example to Slack, Teams or email) before an agent runs selected tools (n8n Docs). Use it for anything irreversible or customer-facing: sending messages, deleting records, changing stages. For the conceptual difference, see What is an AI agent? and AI agents vs automation.
The MitHub workflow skeleton: Trigger → Check → Act → Record → Alert
Every production workflow we teach follows the same five-part skeleton, whatever tool it's built in:
- Trigger. Catch the event and respond fast. Save the raw input somewhere before doing anything risky.
- Check. Validate before you spend or act: required fields present? Duplicate? Already contacted? Within allowed hours and channels?
- Act. Do the work: update the CRM, enrich, call an API, run the agent, start the sequence.
- Record. Leave a trace of what happened: status fields in the CRM, a row in a log, the execution ID.
- Alert. When something fails or needs judgment, tell a named human in a channel they actually read.
If a workflow is missing Record or Alert, it will eventually fail silently. That's the principle behind systems thinking for AI automation: design for what happens when things go wrong, not only when they go right.
Typical revenue workflows in n8n
These are common patterns, described generically. Adapt the apps to your stack.
1. Speed-to-lead
Webhook receives a new lead → normalize phone and email → check the CRM for duplicates → create or update the record → assign an owner by territory or location → trigger an immediate call, message or alert → log the time from submission to first action.
2. Enrichment round-trip
New CRM lead → send to an enrichment tool (such as a Clay table) → receive the enriched, scored result on a second webhook → update the CRM → route by score. The full design is in Clay vs n8n.
3. After-call processing
A calling platform posts the call result → an AI step extracts outcome, next step and objections into fixed fields → update the CRM stage → create a follow-up task or book the callback → notify the owner if a transfer or appointment happened.
4. Stale-lead sweep
Schedule trigger every morning → find leads with no activity in a set period → apply rules (retry, move to nurture, flag bad contact data) → post a short summary to the team channel.
5. Bad-data quarantine
When a phone number fails or an email bounces → mark the record → send it for re-enrichment or human review → keep it out of automated outreach until fixed.
6. Reporting feed
Schedule trigger → pull counts from the CRM and calling or email tools → write to a sheet or database → post a daily snapshot. This is the fourth of MitHub's four families, data & reporting, and it's often the quickest win because it makes every other workflow measurable.
Error handling basics
Things will fail: an API times out, a credential expires, a field is empty, a rate limit hits. The question is whether you find out.
Error workflows
In n8n you can assign an error workflow to any workflow in its settings. When an execution fails, n8n runs the error workflow, which must start with the Error Trigger node. It receives details such as the workflow name, the last node executed, the error message and a link to the execution, and the same error workflow can serve many workflows (Handle errors gracefully).
A good default error workflow: Error Trigger → format a short message (which workflow, which node, what error, link) → post to the team's alert channel → append a row to an error log.
Failing on purpose
Some problems don't throw errors. An API can return "success" with an empty result. The Stop and Error node lets you force a failure under conditions you choose, which then triggers your error workflow (Handle errors gracefully). Example: if a lead reaches the "assign owner" step with no owner found, stop and error instead of silently continuing.
Habits that prevent silent failures
- Validate the business result, not just the execution. Open the CRM record and check the fields actually changed. A green run proves the workflow ran, not that the lead was handled.
- Make steps safe to rerun. Search before create, so a retry doesn't produce duplicates.
- Keep a stuck-record sweep. A scheduled workflow that finds records waiting too long in an intermediate status catches failures that never raised an error.
- Use execution history to debug. Open the failed run, see the data at each node, fix, and test with the same data.
- Name workflows and nodes clearly. "Assign owner by branch" beats "IF3" when someone else is on call.
How to start learning n8n
- Pick one manual handoff you can see, like copying form leads into a CRM.
- Build it with the five-part skeleton, on the test webhook first.
- Add an error workflow before you publish.
- Run it on real data for a week and check outcomes by hand every day.
- Write up what you built, what broke and what you changed. That's proof of work, and it's the heart of the Build and Prove stages of MitHub's journey.
Next, go deeper with n8n for AI automation, or step back to the bigger picture in What is AI automation?. If you want the structured path, the Faculty of Revenue Reverse Engineering starts free.