Most N8N beginners start with scheduled workflows. Every hour, check this spreadsheet. Every Monday, send this report. That pattern works well for a lot of tasks. But it has a fundamental limitation: latency. A scheduled workflow can only react to something as fast as its next scheduled run.
If a new lead fills out your form at 2:47pm and your workflow runs on the hour, that lead sits uncontacted for 13 minutes. Your competitor's sales rep — or their automation — may have already called them. In B2B sales, speed-to-lead inside five minutes increases qualification rates by 400% compared to responding after 10 minutes, according to industry data tracked across multiple client deployments.
Event-driven automation solves this. Instead of polling on a schedule, your N8N workflow sits and waits for the world to send it something. The moment an event fires — a Stripe payment fails, a Calendly appointment is booked, a Shopify order ships — N8N responds within milliseconds. No polling lag, no waiting for the next run.
This guide walks through the architecture behind event-driven N8N workflows, the core nodes you need, and five practical business use cases with the conditional logic that makes them actually useful. If you want to see a comparison of N8N against other platforms for automation costs, check the ROI calculator first to understand what the right tooling is worth to your business.
Scheduled vs. Event-Driven: Choosing the Right Pattern
Before building anything, it helps to understand where each pattern excels. Most production automation setups use both.
| Factor | Scheduled (Cron / Schedule Node) | Event-Driven (Webhook Trigger) |
|---|---|---|
| Response time | Up to your interval (1 min, 1 hour) | Under 1 second of triggering event |
| Best for | Batch jobs, reports, syncs, digests | Lead response, payment events, form submissions |
| Resource use | Runs even when nothing changed | Only runs when there is something to process |
| Setup complexity | Simple — set a time and go | Requires the source app to support webhooks |
| Reliability | Very high — predictable execution | Depends on source app delivery guarantees |
| N8N trigger node | Schedule, Cron | Webhook, app-specific trigger nodes |
The rule of thumb: if timing matters and the triggering action happens in an external system, use event-driven. If you are processing a batch of existing data on a known schedule, use a cron trigger. Mixing both in a single workflow is also valid — for example, a webhook receives a new order and triggers a real-time confirmation email, while a separate scheduled workflow sends a daily summary of all orders to the warehouse team.
The Core Building Blocks
The Webhook Node: Your Event Listener
The Webhook node is the entry point for all event-driven workflows in N8N. When you add it, N8N generates a unique URL — something like https://your-n8n.example.com/webhook/abc123-xyz. You paste that URL into any app's webhook settings, and from that moment on, every time that app fires the event you configured, it sends an HTTP POST to your N8N workflow with a JSON payload containing event data.
N8N provides two webhook URLs: a test URL (active only when you are in the editor running a test) and a production URL (always listening when the workflow is activated). For building and debugging, always use the test URL first.
The webhook node can be configured to accept GET or POST requests, require HTTP authentication, and respond immediately with a custom payload — useful when the source app expects a confirmation response to consider the webhook delivered.
For apps that have N8N-native trigger nodes (HubSpot, Stripe, Shopify, Typeform, Calendly, and many others), you can use those instead of the raw Webhook node. They handle authentication and parse the payload automatically, saving you extra steps.
The IF Node: Binary Decision Branches
Once your webhook receives data, you almost never want to do the same thing with every payload. A new contact in HubSpot might be a hot lead from a demo request form, or it might be a cold contact manually added by a sales rep cleaning up their spreadsheet. Those two scenarios warrant completely different next steps.
The IF node evaluates a condition against the incoming data and splits your workflow into two paths: true and false. You can combine multiple conditions with AND or OR logic. Common use cases:
- Is the deal value above $5,000? True branch: assign to senior rep + notify VP. False branch: standard drip sequence.
- Did the payment fail due to insufficient funds? True branch: send a gentle retry email. False branch (card error): send a card update request.
- Is the support ticket tagged "urgent"? True branch: page on-call. False branch: add to normal queue.
IF nodes are chainable — you can stack them to create multi-level decision trees, though once you have more than three conditions in a chain, the Switch node becomes cleaner.
The Switch Node: Multi-Path Routing
The Switch node reads a single field from your data and routes to different output branches based on its value. Think of it as a traffic director for event types.
This becomes essential when one webhook endpoint receives multiple event types from the same platform. Stripe, for example, sends dozens of event types to a single webhook URL: payment_intent.succeeded, payment_intent.payment_failed, customer.subscription.deleted, invoice.payment_failed, and more. A Switch node at the start of your workflow reads the type field from Stripe's payload and routes each event to the branch that handles it correctly.
Without the Switch node, you would need a separate N8N workflow — and a separate webhook URL — for every event type. With it, one workflow handles your entire Stripe integration cleanly.
Five Real Business Workflows
1. Instant Lead Response and Routing
Scenario: A prospect fills in a demo request form. You want the right sales rep notified within 30 seconds and a personalized confirmation email sent to the prospect immediately.
Trigger: Typeform or Tally webhook fires when the form is submitted. Payload includes the prospect's email, company name, and their answer to "What's your monthly revenue?"
Workflow structure:
- Webhook node receives form submission
- IF node: Is monthly revenue above $50,000? True branch = enterprise track. False branch = SMB track.
- Enterprise branch: Create contact in HubSpot with "Enterprise" tag, post to #enterprise-leads Slack channel, assign to senior rep via HubSpot task
- SMB branch: Create contact in HubSpot with "SMB" tag, add to lead nurturing sequence, send to standard Slack channel
- Both branches: Send personalized confirmation email via Gmail or SendGrid, including a Calendly link for booking
Total workflow execution time: under 2 seconds from form submit to confirmation email delivered. Compare that to checking a form inbox every 20 minutes. At Le Marquier, implementing real-time lead routing as part of a broader automation overhaul reduced their customer service cost by 80% while achieving a 98% AI handling rate. See the full Le Marquier case study for the breakdown.
2. Payment Failure Recovery
Scenario: A SaaS or subscription business needs to handle failed payments without losing the customer to churn.
Trigger: Stripe webhook fires on payment_intent.payment_failed. Payload includes the customer's email, the failure reason code, and the amount.
Workflow structure:
- Webhook node receives Stripe event
- Switch node: Route on
event.type— separate branches forpayment_intent.payment_failed,invoice.payment_failed, andcustomer.subscription.deleted - Inside the payment_failed branch, a second Switch node reads the
decline_codefield:insufficient_funds: Send a soft email suggesting they try in a few days, schedule an automatic retry in 3 days via a Wait nodecard_declined/expired_card: Send email with a direct link to update billing info- Other: Standard recovery email + flag in CRM for manual follow-up
- Log all failures to a Google Sheet for weekly churn analysis
This workflow recovers failed payments faster and with more context than any scheduled polling approach could achieve. The conditional routing on decline codes is key — a message about insufficient funds to someone whose card expired looks tone-deaf and reduces recovery rates.
3. Support Ticket Triage and Escalation
Scenario: Customer support tickets come in through multiple channels. Some need immediate human attention. Most can wait in a queue.
Trigger: Zendesk, Freshdesk, or a custom form webhook fires when a new ticket is created. Payload includes the ticket subject, body text, customer tier (scraped from CRM or included in the form), and priority.
Workflow structure:
- Webhook node receives new ticket event
- First IF node: Is the customer tier "Enterprise"? True = fast-track branch. False = standard branch.
- Inside the fast-track branch, a second IF node: Does the ticket body contain any of the keywords "down", "outage", "broken", "not working"? True = critical escalation (page on-call via PagerDuty/Slack). False = assign to senior support rep with 2-hour SLA tag.
- Standard branch: Run subject text through an AI classification node (N8N has OpenAI and Claude nodes built in) to categorize as billing, technical, feature request, or general. Route each category to the appropriate team's Slack channel.
- All branches: Create or update ticket in CRM, set SLA timestamp, log to operations sheet.
4. E-Commerce Order Events
Scenario: A Shopify store needs different automations for different order states: placed, fulfilled, delivered, and refunded all trigger different team actions.
Trigger: Shopify webhook sends events to N8N for orders/create, orders/fulfilled, orders/updated, and refunds/create.
Workflow structure:
- Webhook node receives Shopify event
- Switch node routes on
X-Shopify-Topicheader or event type field:orders/create: Add to fulfillment sheet, send order confirmation SMS via Twilio, notify warehouse Slack channelorders/fulfilled: Send shipping confirmation email with tracking link, update customer record in CRMrefunds/create: Send refund confirmation email, deduct inventory in fulfillment sheet, flag in retention dashboard
One workflow, one webhook URL, four different customer experiences — each handled correctly based on what actually happened. This is the architectural elegance of event-driven design.
5. New Employee Onboarding Trigger
Scenario: HR adds a new employee in BambooHR or an internal system. IT, payroll, and the hiring manager each need different things to happen immediately.
Trigger: HR system webhook fires on new employee creation. Payload includes name, department, role, start date, and manager email.
Workflow structure:
- Webhook node receives new employee event
- IF node: Is the start date within the next 7 days? True = immediate action branch. False = schedule reminder for later via Wait node.
- Immediate action branch — parallel execution using N8N's parallel output:
- Create Google Workspace account, add to correct groups based on department
- Create Slack account and add to department channels
- Send welcome email to new employee with Day 1 instructions
- Notify manager with new hire prep checklist
- Create IT ticket for laptop provisioning
Without event-driven automation, each of these steps requires someone to notice the new hire was added and manually kick off the chain. With it, the entire sequence fires in seconds of HR clicking save.
Error Handling in Event-Driven Workflows
Scheduled workflows have a natural advantage in error handling: if something fails, it runs again at the next scheduled time. Event-driven workflows do not. If a webhook fires and your downstream action fails — the CRM API returns a 500, the email service is temporarily down — that event may be gone.
Three practices that protect you:
- Always respond 200 immediately. Configure your Webhook node to respond before executing the rest of the workflow (N8N supports this with the "Respond to Webhook" node). This tells the source app "received" before you begin processing, so it does not retry the delivery thinking you dropped it.
- Use Try/Catch with Error Trigger nodes. N8N has an Error Trigger node that fires when any node in a workflow fails. Connect it to a notification workflow that Slacks you or logs the failure with the full payload, so you can manually replay it.
- Log raw payloads. Before any processing, write the incoming webhook data to a Google Sheet or database. If downstream processing fails, you have the raw event to replay. See the full N8N error handling guide for patterns to implement this cleanly.
Combining Event-Driven and Scheduled Workflows
The most robust production setups use both patterns together. A webhook fires when a new lead arrives — instant response. A scheduled workflow runs every night to reconcile leads that somehow slipped through (the source app had an outage, a webhook delivery failed, manual entries were made directly in the CRM).
This hybrid approach gives you the speed of event-driven automation with the reliability safety net of scheduled reconciliation. The nightly job is not the primary path — it is the fallback. Most nights it finds nothing to do. But when a webhook delivery fails, it catches what slipped through.
If you are evaluating whether your business is ready to implement these kinds of workflows, the AI readiness assessment will help you identify which processes will return the most value from automation first.
Setting Up Your First Event-Driven Workflow
The fastest path to a working event-driven workflow in N8N:
- Add a Webhook node to a new workflow. Copy the test URL.
- Configure the source app. Paste the test URL into the app's webhook settings. Most apps let you choose which event types to send.
- Trigger a test event in the source app — submit a test form, create a dummy record, fire a test payment. N8N will receive the payload in the editor.
- Inspect the payload by clicking the Webhook node. You can see every field in the JSON. Note the field names you want to route on.
- Add an IF or Switch node. Reference the field names from the payload. Build your branches.
- Build out each branch with the actions each scenario needs.
- Activate the workflow and switch your source app's webhook URL to the production URL.
The most common mistake is building the conditional logic before inspecting an actual payload. Field names in documentation do not always match what the app actually sends. Always inspect a real test event first.
If you want to go deeper on webhook mechanics specifically — URL structure, headers, authentication, and responding to the caller — the N8N webhook tutorial covers the low-level plumbing in detail. And for using N8N to qualify and nurture leads after they arrive through these event triggers, see the lead scoring and nurturing workflow guide.
If you want N8N workflows built for your specific business rather than figuring it out yourself, that is what we do. Check the N8N automation service for how we scope and build custom workflows, or take a look at the ROI calculator to estimate what automation is worth for your volume.
Frequently Asked Questions
What is event-driven automation in N8N?
Event-driven automation in N8N means a workflow starts the moment a specific event happens — a form submission, a new CRM contact, a payment failure — rather than running on a fixed schedule. N8N listens for these events through its Webhook node, which receives an HTTP POST from any app that can send one. The workflow then routes data through IF and Switch nodes to trigger the right actions for each scenario.
What is the difference between a scheduled trigger and a webhook trigger in N8N?
A scheduled trigger (Cron or Schedule node) runs your workflow at set intervals — every hour, every Monday at 9am. It is ideal for batch jobs: pulling reports, syncing databases, sending weekly digests. A webhook trigger fires instantly when an external system sends data to a unique URL N8N provides. It is ideal for real-time reactions: sending a welcome email the moment someone signs up, alerting your team when a payment fails, or routing a support ticket to the right person based on its content.
How do I add conditional logic to an N8N workflow?
N8N has two core nodes for conditional logic. The IF node evaluates a single true/false condition — for example, "Is deal value greater than $5,000?" — and sends data down one of two branches. The Switch node handles multiple conditions in one node, routing data to different branches based on a field's value, such as routing support tickets to different teams based on category. You chain these nodes after your trigger to build decision trees that handle each scenario differently.
Can N8N handle multiple event types from a single webhook?
Yes. Many platforms send different event types to the same webhook URL — Stripe sends payment.succeeded, payment.failed, subscription.canceled, and more from one endpoint. In N8N, you use a Switch node immediately after the Webhook node to read the event type field and route each event to its own branch. This means one workflow URL handles your entire integration with a platform rather than requiring separate webhooks for each event.
Is event-driven automation faster than scheduled polling in N8N?
Significantly faster. Polling workflows run at intervals — at best every minute — meaning a new lead could wait 59 seconds before your workflow fires. Webhook-based event-driven workflows respond in under a second of the triggering event. For time-sensitive actions like lead response, payment failure recovery, or appointment confirmations, that speed difference directly impacts conversion rates and customer satisfaction.
What apps can trigger N8N event-driven workflows?
Any app that supports webhooks or HTTP callbacks can trigger an N8N event-driven workflow. This includes Stripe, Shopify, HubSpot, Typeform, Calendly, WooCommerce, GitHub, Slack, Twilio, PayPal, and hundreds more. For apps without native webhook support, you can still build event-driven behavior using N8N's polling trigger nodes, which check for changes frequently and are more efficient than you building your own polling loop.
Ready to Get Started?
Book a free 30-minute discovery call. We'll identify your biggest opportunities and show you exactly what AI automation can do for your business.