5 pattern n8n che usiamo in produzione

Ogni workflow n8n che costruiamo in produzione si basa su 5 pattern ricorrenti. Non sono scoperte rivoluzionarie: sono regole operative che abbiamo imparato sbagliando. Eccole, con quando usarle e quando NON usarle.

1. Error Trigger node — sempre

Ogni workflow deve avere un Error Trigger collegato a una notifica Telegram o Slack. È letteralmente la prima cosa che creiamo, prima ancora della logica. Motivo: se il workflow fallisce alle 3 di notte, vuoi saperlo subito, non scoprirlo il giorno dopo dai clienti arrabbiati.

2. Provider abstraction via Switch node

I workflow che gestiscono email non devono dipendere da un singolo provider. Switch node basato su una variabile di config (es. user.email_provider) che instrada verso Gmail, Aruba IMAP, o Outlook. Costa 10 minuti in più all'inizio, risparmia settimane quando arriva il primo cliente con PEC Aruba.

3. Approval flow con Wait node

Per azioni critiche (invio mail, modifica dati, pagamenti): il workflow crea un record "pending", manda notifica Telegram con bottoni inline, poi Wait node fino a webhook di risposta. Timeout configurabile (8-24h), dopo il quale scatta fallback o auto-invio secondo regole.

4. Preflight cron giornaliero

Ogni mattina alle 7:30, un workflow che verifica la salute di tutti gli altri: credenziali ancora valide, webhook rispondono, rate limit non esauriti, database accessibile. Report su Telegram al team. Preveniamo il 90% dei problemi prima che li vedano i clienti.

5. Observability con Set + HTTP node

Ogni nodo critico termina con un Set node che compone un log strutturato, poi HTTP node che lo manda a un endpoint interno. Costo: 5 minuti per workflow. Beneficio: quando qualcosa va storto hai log esatti di cosa è passato dove, non log generici di n8n.