Un workflow n8n funziona quando ha un trigger preciso, dati puliti in ingresso e almeno una guardia che blocca l’esecuzione se qualcosa non torna. Senza quella struttura, gira — ma non sai se gira bene. Gli esempi qui sotto seguono quella logica: trigger, trasformazione, azione, guardia.
La maggior parte di chi usa n8n conosce i nodi base. Il problema non è aprire la canvas: è decidere cosa costruire, in che ordine e dove mettere i controlli. Questi esempi partono da scenari reali — lead che arrivano da un form, contenuti da pubblicare, clienti da onboardare — e mostrano la struttura intera, non solo il nodo finale. Coprono casi da agenzia e da infobusiness, con varianti da adattare al proprio stack.
Come leggere questi n8n esempi
Ogni workflow qui ha quattro parti: il trigger che lo avvia, i nodi di trasformazione dei dati, l’azione finale e la guardia. La guardia non è opzionale. Un’automazione senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto — non rallenta, non ti avvisa, produce.
Il formato che uso per descrivere ogni flusso è sempre lo stesso: cosa entra, cosa succede, cosa esce, dove si rompe. Se vedi uno scenario simile al tuo, la struttura è copiabile anche se cambi i nodi specifici.
Esempio 1: routing automatico dei lead da form a CRM
Entra un lead da Typeform o Tally. n8n riceve il payload via webhook, legge il campo «servizio di interesse» e smista il contatto sulla pipeline giusta dentro il CRM. Se il campo è vuoto o ha un valore non mappato, il flusso si ferma e manda una notifica su Slack invece di creare un contatto sporco.
Struttura del flusso
- Trigger: Webhook — riceve il payload dal form
- IF node: controlla che il campo «servizio» sia presente e valido
- Switch node: smista su tre branch in base al valore del campo
- HTTP Request o nodo CRM nativo: crea il contatto nella pipeline corretta
- Slack node sul branch «else»: notifica il team con il payload grezzo
La guardia è il nodo IF all’ingresso. Senza di lui, un form incompleto crea un contatto in una pipeline a caso — e nessuno lo scopre finché il commerciale non chiama qualcuno che non sa perché lo stanno chiamando.
Esempio 2: onboarding automatico dopo pagamento
Un cliente compra. Il pagamento arriva da Stripe. n8n intercetta l’evento checkout.session.completed, verifica che il pagamento sia effettivamente andato a buon fine (stato paid), crea l’accesso alla piattaforma, manda la mail di benvenuto e aggiunge il contatto a una lista specifica su ActiveCampaign o simili. Se la creazione dell’accesso fallisce, il flusso blocca tutto e manda un alert — non manda la mail di benvenuto a un cliente che non può ancora entrare.
Struttura del flusso
- Trigger: Webhook Stripe — evento
checkout.session.completed - IF node: controlla
payment_status === 'paid' - HTTP Request: chiama l’API della piattaforma corsi per creare l’utente
- IF node: controlla che la risposta HTTP sia 200 e che l’utente sia stato creato
- Email node: invia la mail di benvenuto con le credenziali
- ActiveCampaign node: aggiunge il contatto alla lista «Clienti attivi»
- Slack node sul branch di errore: notifica con order ID e email cliente
Il dettaglio che rompe quasi tutti i flussi simili: mandano la mail di benvenuto prima di verificare che l’accesso sia stato creato. Il cliente riceve le credenziali, prova ad accedere, non entra. Il supporto riceve il ticket. Quella sequenza costa tempo e credibilità.
La regola
Un’automazione senza guardie esegue sbagliato in silenzio
Ogni workflow ha un punto dove i dati possono essere sporchi o incompleti. Senza un nodo di controllo in quel punto, il flusso continua comunque — producendo output sbagliati che nessuno vede finché il danno non è già fatto.
- Guardia all’ingresso — verifica i dati prima di qualsiasi azione
- Guardia sull’azione critica — controlla la risposta prima di andare avanti
- Alert sul branch di errore — notifica sempre, anche se sembra un caso raro
Esempio 3: content automation da foglio Google a social
Il piano editoriale vive su un Google Sheet. Ogni riga è un post: data di pubblicazione, testo, immagine, canale. n8n si sveglia ogni mattina alle 8:00 con un trigger a calendario, legge le righe con data uguale a oggi e stato «Approvato», pubblica sui canali indicati e aggiorna lo stato della riga a «Pubblicato». Se la pubblicazione fallisce, lo stato diventa «Errore» con il messaggio di risposta scritto nella colonna accanto.
Struttura del flusso
- Trigger: Schedule — ogni giorno alle 8:00
- Google Sheets node: legge le righe filtrate per data e stato «Approvato»
- IF node: controlla che ci siano righe da processare (evita esecuzioni vuote)
- Split in Batches: processa una riga alla volta
- Switch node: smista su LinkedIn, Instagram, Twitter in base alla colonna «canale»
- Nodo canale specifico: pubblica il contenuto
- Google Sheets node: aggiorna stato a «Pubblicato» o «Errore»
La trappola di questo flusso è la duplicazione. Se costruisci una copia del workflow per ogni cliente, stai accumulando debito tecnico a ogni copia. Quando aggiorni la logica su uno, devi replicarla su tutti gli altri — e quella che salti continua a girare con la versione vecchia. Una tecnica che funziona: un solo workflow con un parametro cliente in ingresso, non venti workflow identici. Se hai già questo problema aperto, qui trovi esempi specifici per agenzie con più clienti da gestire.
Esempio 4: notifiche intelligenti da CRM a team
Un lead cambia stage nel CRM. Il webhook parte. n8n riceve l’evento, controlla che lo stage di destinazione sia uno di quelli che richiedono azione umana (non tutti i movimenti la richiedono), identifica il commerciale assegnato, manda un messaggio su Slack o Telegram con il nome del lead, lo stage raggiunto e il link diretto al contatto nel CRM. Niente mail, niente notifiche generiche: il messaggio va alla persona giusta con il contesto giusto.
Struttura del flusso
- Trigger: Webhook CRM — evento di cambio stage
- Switch node: filtra solo gli stage che richiedono notifica
- Set node: compone il messaggio con nome, stage e URL del contatto
- HTTP Request o nodo Slack/Telegram: invia al canale o utente corretto
La versione sbagliata di questo flusso notifica tutto a tutti. Dopo una settimana il team smette di leggere i messaggi perché sono troppi. La guardia qui è il nodo Switch che filtra gli stage: senza di lui, stai costruendo un sistema di rumore, non di segnale.
Esempio 5: sincronizzazione dati tra due tool senza duplicati
Hai contatti in due sistemi — diciamo un form di iscrizione e un CRM. Ogni volta che arriva un nuovo contatto dal form, devi verificare se esiste già nel CRM prima di crearlo. Se esiste, aggiorni i campi mancanti. Se non esiste, lo crei. Non duplichi mai.
Struttura del flusso
- Trigger: Webhook dal form
- HTTP Request: cerca il contatto nel CRM per email
- IF node: controlla se la ricerca ha restituito un risultato
- Branch «esiste»: HTTP Request di aggiornamento (PATCH) con i campi nuovi
- Branch «non esiste»: HTTP Request di creazione (POST)
- Set node: normalizza la risposta nei due branch prima di procedere
Questo pattern — cerca, poi decidi, poi agisci — è la base di qualsiasi sincronizzazione pulita. La versione senza IF crea duplicati. I duplicati nei CRM costano: campagne che vanno due volte alla stessa persona, report gonfiati, conversazioni di supporto che parlano di account diversi che sono la stessa persona. Per capire dove questo flusso si inserisce in una mappa più larga, qui c’è la logica generale dell’automazione dei processi aziendali.
Se non vuoi gestire un server
Make è l’alternativa per chi vuole la stessa automazione senza pensare all’infrastruttura
Con Make non installi niente, non gestisci aggiornamenti e non presidii l’uptime. Gli stessi flussi descritti qui — routing lead, onboarding, sincronizzazione — si costruiscono con la stessa logica su una piattaforma cloud con piano gratuito da 1.000 operazioni al mese.
- Giorni 1-2 — riproduci il flusso di routing lead con il modulo webhook e i filtri
- Giorni 3-4 — collega il CRM e testa il branch di errore prima di andare live
- Giorno 5 — aggiungi la notifica Slack e verifica che arrivi solo quando serve
Apri il piano gratuito di Make →
Link di affiliazione: se ti iscrivi da qui io prendo una commissione, tu paghi uguale. Lo linko perché ci lavoro dentro ogni giorno.
Dove trovare altri n8n esempi da importare
n8n ha una libreria di template ufficiale su n8n.io/workflows con centinaia di flussi filtrabili per categoria e integrazione. La qualità varia: alcuni template sono scheletri da completare, altri sono pronti da importare con poche modifiche. Il filtro più utile è per numero di nodi — i flussi sotto i 10 nodi sono spesso i più adattabili.
La community pubblica anche su GitHub. Qui trovi i template GitHub più scaricati con una selezione già fatta. L’importazione è diretta: copi il JSON, apri n8n, vai su «Import from clipboard» e il flusso appare sulla canvas. Poi sostituisci le credenziali e testi.
Per chi sta costruendo agenti AI sopra questi flussi, il passaggio successivo è strutturato: costruire il primo agente intelligente in n8n richiede gli stessi principi — trigger pulito, dati strutturati, guardia sull’output del modello.
Self-hosted vs cloud: cosa cambia per questi esempi
I workflow qui funzionano su entrambe le versioni di n8n. La differenza pratica è nella gestione degli webhook pubblici: su n8n self-hosted hai bisogno di un dominio e un reverse proxy configurato correttamente perché i webhook siano raggiungibili dall’esterno. Su n8n cloud è già tutto esposto. Se stai ancora valutando dove girare, considera che il self-hosted ti dà controllo totale su dati e costi, ma aggiornamenti e uptime sono tuoi.
| Aspetto | n8n self-hosted | n8n cloud |
|---|---|---|
| Costo base | ~5€/mese (VPS) | Da 20$/mese |
| Webhook pubblici | Richiede dominio + proxy | Inclusi e pronti |
| Aggiornamenti | Manuali | Automatici |
| Limite esecuzioni | Nessuno | Per piano |
| Accesso ai log | Completo | Limitato per piano |
Se vuoi partire in self-hosted con una spesa minima, qui c’è il tutorial per installare n8n su Hostinger sotto i 5€ al mese. Se preferisci partire in locale prima di esporre qualcosa su un server, l’installazione locale è documentata qui.
Gli esempi qui sopra sono la parte visibile. La parte che non si vede — e che decide se un workflow regge in produzione — è la struttura di controllo: quanti IF node hai messo, dove vanno gli errori, chi riceve la notifica quando qualcosa smette di girare. Il silenzio dei sistemi non è salute. Un flusso che non produce errori potrebbe semplicemente non stare controllando niente.
Domande frequenti
Posso importare questi esempi direttamente in n8n?
Sì. n8n accetta l’importazione di workflow in formato JSON dalla canvas, tramite il menu «Import from file» o «Import from clipboard». I flussi della libreria ufficiale si importano con un click. Per i workflow custom descritti in questo articolo, devi ricostruirli nodo per nodo o usare un template JSON compatibile.
Quanti workflow posso avere attivi contemporaneamente?
Su n8n self-hosted non c’è un limite tecnico imposto dalla piattaforma: il limite è la capacità del tuo server. Su n8n cloud il numero di workflow attivi dipende dal piano scelto. In entrambi i casi, workflow complessi con molti nodi pesano più di flussi semplici.
Cosa succede se un workflow n8n va in errore?
Di default n8n registra l’errore nei log di esecuzione e si ferma. Non ti avvisa in modo proattivo. Per ricevere una notifica devi aggiungere un nodo di errore esplicito — Slack, email, Telegram — collegato al branch di fallimento. Senza quel nodo, il flusso fallisce in silenzio.
È meglio usare n8n o Make per questi workflow?
Dipende da un fattore solo: vuoi gestire un server o no. n8n self-hosted costa meno e non ha limiti di operazioni, ma aggiornamenti e uptime sono tuoi. Make è cloud, non richiede infrastruttura, ha un piano gratuito da 1.000 operazioni al mese. La logica dei flussi è identica nelle due piattaforme.
Trasparenza: in questo articolo c’è un link di affiliazione. Se ti iscrivi da lì io ricevo una commissione, per te non cambia niente. Linko solo strumenti che uso in produzione.
