Quando i tuoi workflow crescono, le catene di IF diventano difficili da leggere e mantenere. Il nodo switch n8n è la risposta: un “multi‑IF” che smista gli item su più uscite in base a regole chiare, con un percorso di fallback predefinito. In questa guida imparerai a scegliere quando usare Switch rispetto a IF, come configurare le modalità “Rules” ed “Expression”, e quali operatori adottare per stringhe, numeri, date, booleani, array e oggetti. Vedrai esempi reali per smistare ordini/ticket per stato o valore, applicare soglie numeriche e intervalli temporali e fare dispatch verso servizi diversi (Slack, CRM, email). Includeremo configurazioni esatte, snippet pronti e consigli per migliorare leggibilità, manutenzione e branching su più rami. Obiettivo: rendere i tuoi flussi più chiari, scalabili e facili da modificare, così il tuo team marketing automatizza con sicurezza e senza tecnicismi inutili.

[IMG: Panoramica di un workflow con Switch che indirizza su tre rami (Support, Sales, Fallback)]

---

Cos’è lo Switch e quando usarlo (invece di catene di IF)

Il nodo switch n8n è l’equivalente del costrutto “switch/case” dei linguaggi di programmazione: riceve un item, valuta una serie di regole e lo invia all’uscita corrispondente. A differenza di più nodi IF in serie, Switch:

• Riduce la complessità rispetto a catene di IF
• Migliora leggibilità, manutenzione e branching su più rami
• Offre un chiaro fallback quando nessuna regola corrisponde

Quando preferirlo a IF multipli:

• Hai 3+ rami alternativi (es. stato ordine: new, processing, shipped, canceled)
• Le condizioni sono tra loro esclusive o prevedono un solo match “migliore”
• Vuoi centralizzare il routing in un solo punto e ridurre linee “a ragnatela”

Quando restare su IF:

• Condizioni annidate molto specifiche
• Verifiche complesse che richiedono pre‑calcolo in Code/Function
• Branching condizionale con molte dipendenze tra rami

Use case ricorrenti per marketer:

• Smistamento per stato (ordini/ticket)
• Soglie numeriche e intervalli temporali (es. valore ordine, giorni dalla creazione)
• Dispatch verso servizi diversi (notifica Slack, invio email, scrittura su CRM)

[IMG: Esempio visivo: tre IF sostituiti da un solo Switch con uscite 0/1/2]

---

Modalità e parametri chiave: Rules vs Expression

Il nodo switch n8n (node type: n8n-nodes-base.switch) supporta due modalità operative.

1) Rules (regole dichiarative)

• dataType: specifica il tipo del valore da confrontare (es. “string”, “number”, “dateTime”, “boolean”, “array”, “object”)
• value1: il valore di input o un’espressione, es. ={{ $json[“category”] }}
• rules: elenco di condizioni; ogni regola ha un operation (es. “equal”) e un value2 da confrontare
• fallbackOutput: indice dell’uscita di fallback (0‑based) se nessuna regola corrisponde
• Opzioni di regola (Rule options) tipiche:
• Fallback (obbligatorio consigliato)
• Ignore case (per stringhe)
• Type validation (convalida/convertibilità del tipo)
• Multiple matches (può inviare l’item a più uscite se più regole corrispondono)

2) Expression (instradamento con indice calcolato)

• Number of outputs: numero di uscite del nodo
• Output index: espressione che calcola a quale uscita inviare l’item (0‑based)

Modalità consigliata:

• Preferisci “Rules” quando le condizioni sono leggibili come confronti dichiarativi (equal, contains, greaterThan, ecc.).
• Usa “Expression” quando il routing dipende da logica custom compatta (es. mappa priorità → indice d’uscita in un’unica espressione).

[IMG: Pannello Switch con modalità “Rules”, dataType=string, value1={{$json.category}}, fallbackOutput=2]

---

Regole di routing per tipo: operatori e esempi pratici

Lo Switch supporta comparatori per diversi tipi.

String

• Operator tipici: equal, not equal, contains, not contains, regex
• Esempio: instradare ticket per topic
• dataType: “string”
• value1: ={{ $json[“category”] }}
• rules: equal “support” (Output 0), equal “sales” (Output 1)
• Opzione: Ignore case abilitata se le categorie possono arrivare con maiuscole/minuscole miste

Number

• Operator: equal, greater than, less than, between
• Esempio: soglie numeriche (valore ordine)
• dataType: “number”
• value1: ={{ $json[“total”] }}
• rules: greaterThan 200 (VIP → Output 0), between 50‑200 (Std → Output 1)
• fallbackOutput: 2 (Low value)

Date & Time

• Operator: before, after, between, is today
• Esempio: intervalli temporali (ordini recenti)
• dataType: “dateTime”
• value1: ={{ $json[“created_at”] }}
• rules: after “now‑24h” (Output 0), between “now‑7d” e “now‑24h” (Output 1)
• fallback: 2 (più vecchi)

Boolean

• Operator: is true, is false
• Esempio: cliente “VIP?” true/false per decidere priorità

Array

• Operator: contains, length greater than
• Esempio: line items contiene un certo SKU? Se sì, instrada verso fulfillment dedicato

Object

• Operator: property exists, property equals
• Esempio: se esiste customer.tags e contiene “wholesale”, manda su canale B2B

Suggerimenti:

• Abilita Type validation se ricevi input eterogenei
• Aggiungi una regola “catch‑all” con fallbackOutput per evitare item “persi”

---

Fallback, più match e modalità Expression: come governare i rami

Fallback

• Imposta sempre fallbackOutput (indice 0‑based). Esempio: 2 invia all’Output 2 quando nessuna regola corrisponde.
• Usa il fallback per logging/monitoraggio e per evitare “buchi” nel flusso.

Multiple matches

• Puoi permettere che l’item vada su più uscite se soddisfa più regole (utile con tag multipli). Ricorda che questo genera copie dell’item su più rami: pianifica di conseguenza.

Expression mode

• Scenario: vuoi calcolare l’uscita con una sola espressione (es. in base a una mappa priorità→indice).
• Concetto chiave:
• Number of outputs: definisci quante uscite ha il nodo
• Output index: espressione che restituisce 0, 1, 2, … (0‑based)
• Esempio: ={{ $json.priority === ‘high’ ? 0 : ($json.priority === ‘medium’ ? 1 : 2) }}

Best practice

• Rules prima, Expression solo se semplifica davvero
• Documenta nel titolo del nodo la semantica degli Output (0=Support, 1=Sales, 2=Fallback)

[IMG: Switch in modalità “Expression” con Output index calcolato da priorità]

---

Casi d’uso per marketer: dallo smistamento ordini/ticket al dispatch multicanale

Smistamento per stato (ordini/ticket)

• Stato ordine: “paid”, “partially_refunded”, “refunded” → tre rami con azioni dedicate (notifica finance, update CRM, alert QA)
• Ticket support: “new”, “in_progress”, “waiting”, “resolved” → invia a team/kanban differenziati

Soglie numeriche e intervalli temporali

• Valore ordine: >200€ → canale VIP; 50‑200€ → standard; <50€ → silenzioso (solo log)
• Tempo dalla creazione: <24h → alta priorità; 1‑7 giorni → normale; >7 giorni → escalation o chiusura

Dispatch verso servizi diversi

• Slack per notifiche operative, email per clienti interni/esterni, CRM per aggiornamenti di pipeline, sheet/DB per registrazioni
• Usa Switch per scegliere il canale in base a tag, paese, metodo di spedizione o canale di vendita

Insight unico

• Pre‑calcola una “routing key” in un nodo Code che incapsula le regole di business (es. “vipintlexpress”), poi usa Switch con poche regole chiare. Così disaccoppi il “come calcolare” dal “dove instradare”, migliorando manutenzione.

---

Configurazione esatta: esempio completo in modalità Rules

Ecco una configurazione esemplificativa per istradare per categoria con fallback. Nota: gli indici di uscita sono 0‑based e le regole sono valutate nell’ordine.

{
  "name": "Route by Category",
  "type": "n8n-nodes-base.switch",
  "typeVersion": 2,
  "parameters": {
    "mode": "rules",
    "dataType": "string",
    "value1": "={{ $json[\"category\"] }}",
    "rules": [
      { "operation": "equal", "value2": "support" },
      { "operation": "equal", "value2": "sales" }
    ],
    "fallbackOutput": 2
  }
}

Come leggerlo:

• dataType: “string” — il confronto sarà testuale
• value1: la proprietà “category” dell’item
• rules:
• Regola 0 (Output 0): category == “support”
• Regola 1 (Output 1): category == “sales”
• fallbackOutput: 2 (Output 2 per tutti gli altri casi)

Consigli pratici:

• Abilita “Ignore case” se previsto (es. “Support”, “support”, “SUPPORT”)
• Aggiungi una metrica/contatore nel ramo fallback per monitorare i casi non mappati (segno che serve aggiornare le regole)

[IMG: Switch configurato con due regole e un fallback su Output 2]

---

Testing, performance e manutenzione

Testing

• Prepara item di test rappresentativi (match singolo, multipli, nessun match)
• Usa il fallback come “sentinella”: logga e notifica quando il volume di fallback cresce

Performance

• Preferisci Switch a catene di IF per ridurre nodi e connessioni
• Se attivi “Multiple matches”, considera l’effetto sul carico a valle (lo stesso item replicherà su più rami)

Manutenzione

• Nomina chiaramente il nodo (“Switch: Category → 0=Support,1=Sales,2=Fallback”)
• Documenta nel workflow quali sono le uscite e chi le “possiede”
• Versiona le regole: un tab “routing_map” (sheet/DB) può alimentare il tuo Switch, riducendo deploy per piccoli cambi

Affidabilità

• Aggiungi nodi IF o validazioni di tipo a monte del Switch se il dato è rumoroso
• Pre‑normalizza (lowercase/trim) in un nodo Code per ridurre sorprese su stringhe

---

Quick Takeaways

• Usa il nodo switch n8n per sostituire catene di IF: più chiaro, meno errori.
• Scegli “Rules” per confronti dichiarativi e “Expression” quando un indice calcolato semplifica il routing.
• Imposta sempre un fallbackOutput (0‑based) e monitora i casi non mappati.
• Applica operatori per tipo (string/number/date/boolean/array/object) e abilita Type validation/Ignore case quando serve.
• Testa match singolo, multiplo e nessun match; attenzione al comportamento con “Multiple matches”.
• Documenta la semantica degli output nel titolo del nodo e mantieni regole centralizzate.

---

Conclusione

Il nodo switch n8n ti consente di modellare branching complessi in modo leggibile e robusto. Con le modalità Rules ed Expression, operatori per tutti i principali tipi e un fallback chiaro, trasformi il routing da “spaghetti logic” a un costrutto elegante e facile da mantenere. Per i marketer, significa automazioni più veloci da creare, più semplici da spiegare ai colleghi e più sicure in produzione. Inizia mappando i casi principali (stato, priorità, valore), imposta il fallback e misura quante volte viene usato: sarà la bussola per migliorare le regole. Poi raffina con normalizzazione, validazioni e – se serve – una “routing key” calcolata a monte. Con poche accortezze, lo Switch diventa il centro di gravità dei tuoi flussi, aiutandoti a scalare senza perdere controllo.

---

FAQ

1) Quando ha senso usare Switch invece di più IF?
Quando hai più di due rami alternativi o vuoi centralizzare le condizioni in un solo nodo, migliorando leggibilità e manutenzione del branching su più rami.

2) Cosa succede se nessuna regola corrisponde?
Configura un fallbackOutput (indice 0‑based). È la via di uscita di default e andrebbe sempre monitorata per capire se mancano regole.

3) Posso inviare lo stesso item su più rami?
Sì, con l’opzione “Multiple matches” lo stesso item può passare a più uscite se soddisfa più regole. Ricorda l’impatto sul carico dei rami a valle.

4) Come gestisco confronti su date e numeri?
Imposta dataType appropriato (“dateTime” o “number”) e usa operatori come greaterThan, lessThan, between, before/after. Valida a monte il formato e normalizza se necessario.

5) Meglio Rules o Expression?
Usa Rules per confronti dichiarativi chiari (equal/contains/greaterThan…). Expression è utile quando puoi esprimere l’uscita come un indice calcolato con una sola espressione.

---

Ci dai una mano?

Qual è il primo flusso in cui sostituirai una catena di IF con lo Switch: smistamento ticket, ordini per valore o dispatch multicanale? Condividi la tua scelta e questo articolo con il team per confrontare pattern e velocizzare i prossimi workflow!