Con l’azione If/Else di GoHighLevel un contatto entra nel primo ramo la cui condizione è vera e si ferma lì. Se hai un form dove il lead può scegliere più servizi — diciamo idraulica, elettricità e muratura — e le sceglie tutte e tre, l’If/Else lo manda solo nel ramo «idraulica» e ignora il resto. Il router GoHighLevel funziona diversamente: controlla ogni ramo, uno dopo l’altro, ed esegue tutti quelli la cui condizione è vera.
Questo articolo copre la differenza concreta tra le due azioni, i tre tipi di ramo del Router (Custom rules, Always run, Fallback), gli operatori disponibili e le trappole che fanno perdere contatti senza generare nessun errore visibile. Niente errori rossi, niente alert: il contatto sparisce in silenzio nel ramo sbagliato, o non entra da nessuna parte.
If/Else contro router GoHighLevel: la differenza che cambia la macchina
L’If/Else è un bivio. Valuta le condizioni dall’alto verso il basso, trova la prima vera e manda il contatto in quel ramo. Le condizioni successive non vengono nemmeno controllate. Per molti casi va benissimo: se vuoi separare i lead che hanno già acquistato da quelli che non hanno acquistato, un bivio è tutto ciò che ti serve.
Il problema arriva quando le condizioni non si escludono a vicenda. Un lead può essere interessato a due servizi, abitare in due zone di copertura, avere due tag attivi. L’If/Else in quei casi esegue sbagliato con la stessa sicurezza con cui esegue giusto: non rallenta, non segnala nulla, produce.
Il Router risolve questo con una logica diversa: non è un bivio, è una sequenza di controlli indipendenti. Entra nel workflow un contatto, il Router valuta il ramo 1 — condizione vera, lo esegue. Poi valuta il ramo 2 — condizione vera, lo esegue. Poi il ramo 3 — condizione falsa, lo salta. L’ordine di esecuzione è da sinistra a destra nella lista dei rami, e questo ha conseguenze pratiche su cui torno tra poco.
| Comportamento | If/Else | Router |
|---|---|---|
| Rami eseguiti per contatto | 1 (il primo vero) | Tutti quelli con condizione vera |
| Condizioni successive al primo match | Ignorate | Valutate sempre |
| Esecuzione parallela dei rami | n.d. | No, uno dopo l’altro |
| Ramo per chi non combacia con nulla | Else (implicito) | Fallback (da aggiungere) |
| Ramo incondizionato | No | Always run |

I tre tipi di ramo nel router GoHighLevel
Quando apri un ramo del Router trovi un campo Branch Type con tre opzioni. Capire cosa fa ognuna evita la maggior parte delle trappole.
Custom rules
È il ramo condizionale standard. Gira solo se le condizioni che definisci sotto «Only Continue If» sono vere per quel contatto. Puoi usare più condizioni nella stessa regola e raggrupparle in gruppi separati (OR tra i gruppi, AND dentro ogni gruppo). Gli operatori disponibili coprono i casi più comuni: is, is not, contains, does not contain, is any of, is none of, is not empty. «Is any of» è quello che ti serve quando il campo del form può contenere più valori e vuoi che il ramo scatti se almeno uno di quei valori è presente.
Always run
Nessuna condizione. Gira per ogni contatto che passa dal Router, senza eccezioni. Serve quando hai un passo che deve sempre accadere — aggiungere un tag di tracciamento, inviare una notifica interna al team — indipendentemente da quale servizio ha scelto il lead. Se lo costruisci come ramo Custom rules con condizione sempre vera, funziona lo stesso ma è rumore: Always run è più leggibile e non mente sull’intenzione.
Fallback
Gira solo se nessun altro ramo ha avuto condizione vera. È il ramo di sicurezza. Senza Fallback, un contatto che non combacia con nessuna Custom rule esce dal Router senza che nessuna azione venga eseguita — nessun errore, nessun alert, sparisce nel flusso successivo senza il trattamento che ti aspettavi. Il Fallback può fare cose semplici: una nota interna «lead non classificato», un tag, una notifica a te. Quello che non puoi permetterti è non averlo.
La regola
Ogni Router senza Fallback è incompleto
Un contatto che non combacia con nessuna Custom rule esce silenzioso. Nessun errore, nessun log rosso: il flusso continua come se niente fosse.
- Fallback minimo — una nota interna o un tag basta per tracciare chi è uscito senza classificazione
- Always run separato — usalo per le azioni trasversali, non per simulare il Fallback
- Ordine dei rami — trascinare la maniglia cambia l’ordine di esecuzione, non solo la visualizzazione
Come si configura il Router nel workflow GoHighLevel
Nel builder del workflow clicca il + per aggiungere un’azione e cerca «Router». Una volta inserito, il nodo mostra i rami disponibili come colonne.
Per ogni ramo:
- Aprilo e assegna un Branch Name leggibile — il nome che vedi nel builder e nei log del test.
- Scegli il Branch Type tra Custom rules, Always run e Fallback.
- Se è Custom rules, aggiungi le condizioni sotto «Only Continue If». Scegli il campo del form o del contatto, l’operatore e il valore. Per campi multi-valore usa «is any of».
- Clicca «Add branch» per aggiungere un altro ramo. Puoi traschinare la maniglia per cambiare l’ordine.
- Sotto ogni ramo aggiungi le azioni specifiche di quel percorso: note interne, notifiche al team, tag, task.
- Salva l’azione.
L’ordine dei rami nella lista è l’ordine in cui vengono eseguiti. Se il ramo «Idraulica» è il primo e il ramo «Elettricità» è il secondo, il contatto che ha scelto entrambi esegue prima tutto il ramo Idraulica e poi tutto il ramo Elettricità. I rami non girano in parallelo: uno deve finire prima che inizi il successivo. Se il ramo Idraulica ha un’attesa di 24 ore dentro, il ramo Elettricità aspetta.

Testare il router GoHighLevel e leggere l’output
La funzione «Test workflow» su un evento reale — per esempio un form già inviato — produce un output che elenca ogni ramo con il risultato della valutazione: Passed o Failed, e il motivo. Vedi il valore reale del campo del contatto confrontato con la condizione che hai scritto. Se il ramo non scatta quando dovrebbe, qui trovi se il valore nel CRM è scritto diversamente da come lo hai messo nella condizione — una maiuscola, uno spazio, un carattere diverso nel campo multi-select.
Questo è il modo corretto di verificare le condizioni, non fare ipotesi a occhio nel builder. La documentazione ufficiale di GoHighLevel descrive questo output come la lista di ogni condizione con Passed e il motivo specifico, incluso il valore reale del contatto al momento del test. Usalo prima di mettere in produzione qualsiasi Router con più di due rami.
Quando il router serve davvero e quando no
Il Router serve ogni volta che le condizioni non si escludono a vicenda. Form con checkbox multipli, contatti con più tag attivi, campi che possono contenere più valori: questi sono i casi per cui esiste. Per automatizzare un’agenzia che gestisce clienti su più servizi o più verticali, il Router è lo strumento che evita di duplicare workflow o costruire catene di If/Else annidati per intercettare la seconda e la terza corrispondenza.
Il Router non sostituisce ogni If/Else. Se le condizioni si escludono a vicenda — il lead è nuovo oppure è già cliente, non può essere entrambe — l’If/Else è più leggibile e più diretto. Usare il Router dove basta un bivio aggiunge complessità senza leva. La scelta tra i due non è una questione di preferenza: dipende da se le condizioni possono essere vere contemporaneamente o no.
Se stai costruendo workflow più articolati e vuoi capire la struttura generale prima di arrivare alle azioni specifiche, l’articolo su workflow GoHighLevel e la differenza rispetto alle campagne copre il quadro di partenza. Per il concetto di workflow come sistema che gira da solo — non come diagramma — c’è anche questa guida sul significato di workflow che chiarisce le fondamenta prima dei tool.
Prova GoHighLevel
Gestisci pipeline, messaggi e calendario in un posto solo
Nei primi giorni configura una sub-account di test: importa un form con campi multipli, costruisci un Router con tre rami Custom rules e un Fallback, poi lancia il Test workflow su un contatto reale per vedere l’output ramo per ramo.
- Giorno 1-2 — crea la sub-account di test e collega un form con checkbox multipli
- Giorno 3-4 — costruisci il Router con Custom rules, Always run e Fallback, assegna azioni diverse per ramo
- Giorno 5 — lancia il Test workflow su un contatto reale e leggi l’output: Passed o Failed con il valore effettivo del campo
Attiva la prova di 14 giorni →
Link di affiliazione: se ti iscrivi da qui io prendo una commissione, tu paghi uguale. Lo linko perché ci lavoro dentro ogni giorno.
Le trappole che fanno perdere contatti senza errori
La prima trappola è già stata nominata: nessun Fallback. Un contatto che non combacia con nessun ramo esce senza che nessuna azione venga eseguita, in silenzio.
La seconda è confondere «i rami girano tutti» con «i rami girano in parallelo». Non è così. Se il ramo 1 ha un’attesa, il ramo 2 aspetta che finisca. Se stai costruendo notifiche a team diversi e vuoi che arrivino quasi insieme, l’ordine dei rami e le attese dentro ogni ramo contano.
La terza è il valore del campo. Il Router confronta il valore nel CRM con quello che hai scritto nella condizione. Se il form usa «Idraulica» con la maiuscola e tu hai scritto «idraulica» nella condizione, il ramo non scatta — o scatta, dipende da come GoHighLevel gestisce la case sensitivity per quel tipo di campo. Il Test workflow te lo mostra prima che il problema arrivi in produzione.
La quarta riguarda l’ordine dei rami quando hai un Always run. Se lo metti come primo ramo, esegue sempre per primo. Se dentro ha un’azione che modifica un dato usato dalle Custom rules successive, quelle condizioni vengono valutate sul dato già modificato. Pianifica l’ordine consapevolmente, non lasciarlo al caso della costruzione.
Per chi gestisce più clienti su GoHighLevel e vuole capire come strutturare i workflow a livello di agenzia, l’articolo su automatizzare un’agenzia copre il metodo prima dei singoli strumenti. E se stai valutando GoHighLevel per la tua struttura, questa guida su GoHighLevel in Italia chiarisce cosa aspettarsi prima di adottarlo.
Un Router costruito bene non è complesso: è preciso. La differenza tra i due è che il primo genera rumore da gestire, il secondo gira e non ci pensi più. Metti il Fallback, testa su un evento reale, controlla l’ordine dei rami. Poi passa alla prossima cosa.
Domande frequenti
Il router GoHighLevel esegue i rami in parallelo?
No. I rami vengono eseguiti uno dopo l’altro, nell’ordine in cui compaiono nella lista. Se un ramo contiene un’attesa, il ramo successivo aspetta che quella attesa finisca prima di partire. L’ordine dei rami non è decorativo: è l’ordine di esecuzione reale.
Cosa succede se nessun ramo del Router combacia con il contatto?
Se non hai un ramo Fallback, il contatto esce dal Router senza che nessuna azione venga eseguita. Nessun errore, nessun log di avviso. Per questo ogni Router dovrebbe avere almeno un ramo Fallback, anche se fa solo una nota interna.
Posso usare il router GoHighLevel per workflow condizioni multiple sullo stesso campo?
Sì. Dentro ogni ramo Custom rules puoi aggiungere più condizioni e raggrupparle. L’operatore «is any of» è utile per campi che possono contenere più valori: il ramo scatta se almeno uno dei valori specificati è presente nel campo del contatto.
Come verifico quali rami scattano per un contatto specifico?
Usa la funzione Test workflow su un evento reale, come un form già inviato. L’output elenca ogni ramo con l’esito — Passed o Failed — e il motivo specifico, incluso il valore effettivo del campo del contatto al momento del test.
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.


