Before you begin

You need three things to follow any walkthrough in this library.

• A running n8n instance. Either the hosted version or your own self-hosted install.
• Accounts for the apps you want to connect. Each walkthrough lists these up front on its overview page.
• About 15 to 40 minutes of uninterrupted time. Automations are easy to build and easy to half-build.

Nothing here requires you to write code. A few walkthroughs use short expressions, and every expression is given to you in full so you can copy it.

There are two ways to run n8n and the choice mostly comes down to who you want maintaining it.

Hosted (n8n Cloud) is the fast path. You sign up, you get a URL, and you can build within a couple of minutes. Updates, backups and the webhook URLs are handled for you. This is the right choice if you are learning, or if your automations are for a business that would rather pay than maintain a server.

Self-hosted means you run n8n yourself, usually in a Docker container on a small server. It costs less at scale and keeps your data on infrastructure you control, but you own the upgrades, the backups, and making sure the instance is reachable from the internet when a webhook needs to call it.

Every walkthrough in this library works identically on both. The only difference you will notice is the shape of your webhook URLs.

Everything in n8n happens on a canvas. Four ideas cover almost all of it.

Nodes are the boxes. Each one does a single job: watch a mailbox, call an API, filter a list, send a message.

Connections are the lines between nodes. They carry data from left to right. Whatever a node outputs becomes the input of the node it points to.

Items are the unit of data. A node does not process "a thing", it processes a list of items. If a node receives five items, the node after it usually runs five times, once per item. This single idea explains most surprising behaviour when you are starting out.

The execution is one run of the workflow. Click into any past execution and you can see exactly what data each node received and produced, which is the single most useful debugging tool in the product.

Every workflow begins with exactly one trigger node. The trigger decides *when* the workflow runs. The rest of the nodes are actions, and they decide *what* it does.

There are four trigger styles you will meet constantly:

• Schedule — runs on a timer. Every hour, every weekday at 8am, and so on.
• App event — the connected app tells n8n something happened. A new email, a new row, a new issue.
• Webhook — n8n gives you a URL, and anything that can send an HTTP request can start the workflow.
• Manual — you press the button. This is what you will use while building.

A workflow without an active trigger will never run on its own, no matter how many times you tested it manually. This trips up nearly everyone once.

A credential is a saved connection to an outside service. You create it once, and then every node that talks to that service can select it from a dropdown.

Credentials live separately from workflows on purpose. It means you can export and share a workflow without leaking your API keys, and it means rotating a key is one edit rather than twenty.

Most credentials are created in one of two ways. OAuth pops open the provider's login screen and you approve access, which is the common path for Google, Slack, Microsoft and similar. API key means you paste a token you generated in the other service's settings.

When a walkthrough says "select your Gmail credential", it means the credential you created here, not a password typed into a node.

The fastest way to build a working automation is also the slowest-looking one: add a node, run it, look at the output, then add the next node.

Use Execute step on a single node to run just that node with the data currently sitting on its input. You get an answer in a second or two instead of running the whole chain.

Once a node returns data you are happy with, pin that output. Pinned data stays fixed while you build the nodes downstream, so you are not sending another test email or burning another API call on every attempt. Remember to unpin before you go live.

When something breaks later, open the Executions list. Every run is recorded with the exact input and output of every node, so you can see precisely where the data stopped looking the way you expected.

Before you flip a workflow to Active, run through four things.

1. Unpin every pinned node. Pinned data is ignored in production, but leaving it on makes your test results lie to you.
2. Check what happens on failure. Add an error handling path, or at minimum set the workflow to notify you when an execution fails.
3. Confirm the trigger scope. A trigger watching "all emails" will do exactly that, including the two thousand already sitting in the inbox on some configurations.
4. Run it once for real. Send the actual email, submit the actual form. The first live run is where surprises show up.

Then toggle Active, and check the Executions list an hour later.