What Is a Trigger?
Every workflow in n8n must start somewhere. That starting point is called a trigger node — the first node in any workflow, and the only node that decides when the workflow runs. Without a trigger, a workflow simply sits idle.
There are two broad categories: manual triggers (you start it yourself) and automatic triggers (something external or a schedule starts it). Understanding which trigger to use is one of the most important decisions you make when designing a workflow.
The Three Most Common Triggers
N8n ships with several trigger nodes. You will encounter these three constantly.
The Manual Trigger is the simplest. You click "Test workflow" in the editor and the workflow runs once. It produces no data of its own — it just signals "go". Use this during development or for workflows you only ever run on demand.
The Schedule Trigger runs your workflow automatically at a fixed interval — every hour, every Monday at 9 AM, or any cron expression you define. It also produces no input data; the schedule is just a clock signal.
The Webhook Trigger is the most powerful. N8n exposes a unique URL, and whenever an HTTP request hits that URL, the workflow runs immediately. The incoming request body, headers, and query parameters all become the first piece of data flowing through the workflow. This is how you connect n8n to external services like GitHub, Stripe, or any system that supports webhooks.
When you add a Webhook node, n8n gives you two URLs: a test URL (active only while you have the editor open and click "Listen for Test Event") and a production URL (active only when the workflow is saved and toggled on).
How n8n Processes Data: The Execution Model
Once a trigger fires, n8n creates an execution — a single run of your workflow. Each node runs in sequence, left to right, passing data forward to the next node.
The data model n8n uses is an array of items. Every node receives an array of items and outputs an array of items. Each item is a JSON object wrapped in a structure like this:
When a node receives two items, it typically processes each item individually and outputs two items. This means if your webhook sends one user, the next node processes one record. If an upstream node splits or multiplies data, downstream nodes see more items.
This item-per-row mental model is the key to understanding why things behave the way they do. A node like HTTP Request runs once per item by default. A node like Merge can combine items from two branches into one array. Keeping track of how many items you have at each step prevents most beginner confusion.
You can inspect what happened at any step by clicking a node after a test run — n8n shows you the exact input and output data for that execution.
Active vs. Inactive Workflows
A workflow with a Webhook or Schedule trigger only responds to real events when it is active. Toggling a workflow to active saves it and registers the trigger with n8n's internal scheduler or webhook registry. Toggling it off deregisters the trigger — no more automatic runs.
During development, you almost always work with the workflow inactive, using the Manual Trigger or the test webhook URL to send sample data. Switching to active is the deployment step.
One important side effect: you cannot have two active workflows sharing the same webhook path. N8n will warn you and refuse to activate the second one.
Summary
Every workflow starts with a trigger node. Manual triggers are for development and on-demand use; Schedule triggers run on a clock; Webhook triggers respond to external HTTP calls in real time. Once a trigger fires, n8n creates an execution and moves data as an array of items from node to node, left to right. Workflows with automatic triggers only run when toggled active. Getting comfortable with these fundamentals makes every workflow you build from here much easier to reason about.
Lesson Checkpoint
Review what you learned and get feedback on your work.