Il test workflow GoHighLevel esegue i passi veri del flusso: se hai un’azione Send Email, l’email parte. Se hai Create Opportunity, l’opportunità si crea nel CRM. Non è una simulazione. Per questo la strategia corretta è sempre la stessa: un contatto interno dedicato ai test, e nient’altro.
GoHighLevel mette a disposizione tre livelli di prova, ognuno con un perimetro diverso. Puoi testare solo il trigger, solo una singola azione di un’app esterna, o l’intero workflow dall’inizio alla fine. Capire quale usare — e in quale ordine — è la differenza tra un test che ti dà informazioni e uno che ti lascia dati spazzatura nel CRM. Questo articolo copre tutti e tre i livelli, le trappole più comuni e due funzioni che la maggior parte degli utenti ignora: il tab History con Retry run e Test Action con Data In e Data Out.
Prima di iniziare: il contatto di test
Crea un contatto con la tua email (o una casella interna) prima di toccare qualsiasi pulsante di test. Chiamalo in modo riconoscibile: «TEST Angelo» o «DO NOT CONTACT». Tutti i test che fanno partire email, SMS o azioni su app esterne useranno questo contatto. Se usi il tuo indirizzo reale riceverai le email di test nella tua casella: è il comportamento corretto, non un errore.
Un secondo punto da chiarire subito: il test è facoltativo. GoHighLevel non ti impedisce di pubblicare un workflow senza averlo mai testato. Ma un workflow non testato in produzione è una macchina che esegue sbagliato con la stessa sicurezza con cui esegue giusto — e non ti avvisa.
Livello 1: testare il trigger con Test using events o Enroll a contact
Prima di testare qualsiasi azione devi avere un esempio di trigger salvato. GoHighLevel non ti permette di testare un’azione se il trigger non ha ancora prodotto dati campione.
Hai due strade per far scattare il trigger in modalità test.
Test using events (ascolto attivo)
Clicchi su Test workflow in alto a destra nell’editor, scegli Test using events e poi Start test run. GoHighLevel mette il trigger in ascolto per 15 minuti. In quel lasso di tempo devi compiere l’azione reale che dovrebbe scatenarlo: compilare il form, cambiare uno stato, aggiungere un tag. Se i 15 minuti scadono senza eventi, l’ascolto si chiude e devi riavviarlo.
Questo approccio è utile quando il trigger dipende da un evento di sistema che non puoi simulare diversamente: un webhook in arrivo, un pagamento, una modifica dello stato appuntamento.
Enroll a contact (inserimento manuale)
Se il trigger è del tipo che risponde a condizioni sui contatti — un tag aggiunto, un campo aggiornato, uno stage cambiato — puoi usare Enroll a contact. Selezioni il contatto di test dalla lista e forzi l’ingresso nel workflow saltando l’attesa dell’evento reale.
È la strada più veloce per testare il workflow intero con dati controllati. Usi il contatto interno, sai esattamente cosa ha nei campi, e puoi ripetere il test quante volte vuoi senza aspettare che qualcuno compili un form.
La trappola principale
Per testare un’azione devi prima avere un trigger con esempio salvato
GoHighLevel blocca il Test Action se il trigger non ha ancora prodotto dati campione. L’ordine è fisso: prima testi il trigger, poi testi le azioni.
- Trigger senza dati campione — il pulsante Test Action resta grigio
- Enroll a contact — bypassa l’evento reale e forza l’ingresso del contatto
- 15 minuti — quanto dura l’ascolto con Test using events prima che si chiuda
Livello 2: testare una singola azione con Test Action
Ogni azione che interagisce con un’app esterna — Todoist, Klaviyo, una webhook call, un’integrazione OAuth — ha un pulsante Test Action nel pannello laterale del passo. Cliccarlo fa una chiamata reale all’app e mostra due pannelli: Data In (cosa GoHighLevel ha inviato) e Data Out (la risposta ricevuta).
Questo è il modo corretto di verificare che la connessione funzioni e che i dati mappati siano quelli giusti, senza dover eseguire il workflow dall’inizio ogni volta.
Use this as sample
Dopo un Test Action riuscito, GoHighLevel ti propone Use this as sample. Se lo confermi, blocchi la struttura della risposta come schema di riferimento per i passi successivi. I passo che vengono dopo potranno mappare i campi di quella risposta. Se non lo fai, i passi successivi non vedono i dati dell’azione precedente.
Quando Test Action è disabilitato
Tre cause: l’account dell’app non è collegato, manca un campo obbligatorio nel passo, oppure il trigger non ha ancora un esempio salvato. La terza è la più comune e si risolve tornando al livello 1.
Se l’azione crea dati nell’app esterna — un task in Todoist, un profilo in Klaviyo — i dati si creano davvero. Nomina il record di test in modo riconoscibile («TEST DELETE») e ripulisci dopo. Non è un dettaglio: un CRM che si riempie di record di test è rumore che inquina i report.
Livello 3: testare il workflow intero e leggere gli stati
Il test completo esegue il workflow dal trigger all’ultimo passo, nell’ordine in cui li hai costruiti. Dopo l’avvio, ogni passo sul canvas mostra uno stato. Capire cosa significano evita di perdere tempo a cercare errori che non esistono.
| Stato | Significato | Cosa fare |
|---|---|---|
| Test running | Il passo è in esecuzione | Attendi |
| Success | Il passo ha eseguito senza errori | Clicca per vedere Input e Output |
| Failed | Errore durante l’esecuzione | Clicca il passo, leggi il messaggio di errore |
| Action skipped | Il passo è stato saltato per una condizione non soddisfatta | Verifica la logica If/Else o le condizioni del passo |
| Completed with skipped steps | Il workflow è finito ma almeno un passo è stato saltato | Controlla quali passi e perché |
Cliccando su un singolo passo dopo il test vedi Input e Output: i dati che il passo ha ricevuto e quelli che ha prodotto. È la lettura più utile per capire dove un dato si perde o viene mappato male.
Il tab History e Retry run
Ogni prova eseguita finisce nel tab History dell’editor. Puoi filtrare per Success, Failed o Skipped e riaprire qualsiasi run precedente. Il pulsante Retry run rifà quella prova con gli stessi dati, senza doverla ricostruire da zero. È comodo quando hai corretto un passo e vuoi verificare solo quella correzione senza toccare il resto del flusso.
Test workflow nell’AI Builder
Se usi l’AI Builder per generare o modificare un workflow, il test si avvia direttamente dalla chat con il pulsante Test workflow. Selezioni un contatto o un evento, lanci il run e leggi il riepilogo che l’AI produce. Da lì puoi cliccare Run another test senza uscire dalla chat.
C’è un requisito da non saltare: questa funzione richiede di attivare «The New Test Workflow» in Settings → Labs. Se il pulsante Test workflow non compare nell’AI Builder, è lì che devi guardare prima. La stessa funzione è in uscita come standard dalla versione del 27 ottobre 2026: fino ad allora resta in Labs.
GoHighLevel
Gestisci clienti su GoHighLevel e vuoi tenere pipeline, calendario e messaggi in un posto solo
I primi giorni di prova rendono di più se sai dove guardare. Un piano in tre fasi:
- Giorno 1-2 — collega un calendario e crea una pipeline con almeno tre stage per capire come si muovono i contatti
- Giorno 3-5 — costruisci un workflow semplice (form → tag → notifica interna) e testalo con Enroll a contact prima di pubblicarlo
- Giorno 6-14 — attiva un secondo sottodominio o un sub-account per un cliente reale e replica la struttura
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 non sono ovvie
La documentazione ufficiale di GoHighLevel le elenca, ma è facile non leggerle al momento giusto.
Send Email manda l’email vera. Non c’è modalità «preview only». Se il tuo contatto di test è un cliente reale, il cliente riceve l’email. Usa sempre una casella interna.
Un test riuscito non garantisce che il workflow funzioni per tutti i contatti. Ha funzionato per quel contatto, con quei dati, in quel momento. Condizioni diverse producono percorsi diversi: un workflow con rami condizionali va testato su più contatti che soddisfano condizioni diverse. Su questo, il confronto tra Router GoHighLevel e If/Else chiarisce perché i rami condizionali complessi meritano attenzione separata.
L’ascolto di 15 minuti con Test using events si chiude senza avvertirti se non arriva nessun evento. Non compare nessun messaggio di errore: la finestra si chiude e basta. Se torni sul workflow e non vedi dati campione, è quasi sempre questo il motivo.
Test Action fallisce se il fornitore dell’app è temporaneamente fuori servizio o se l’account ha raggiunto un limite di richieste API. L’errore compare nel pannello Data Out. Non è un problema del workflow: è un problema di disponibilità esterna, e si risolve aspettando o verificando lo stato del servizio.
Per chi costruisce workflow automatizzando un’agenzia, questi livelli di test non sono optional: sono la guardia che impedisce alla macchina di eseguire sbagliato in silenzio. Un’automazione che non hai mai testato in condizioni controllate è una promessa che non hai ancora verificato. Sul tema generale di come strutturare questo tipo di sistemi, la guida per automatizzare un’agenzia copre la logica di progettazione prima dei singoli tool.
Anche la scelta iniziale di cosa automatizzare — campagna o workflow, quando usare l’uno o l’altro — influenza quanto sarà complicato il test. Se non l’hai ancora chiarita, la differenza tra campagne e workflow in GoHighLevel è il punto di partenza.
Le fonti ufficiali di riferimento per tutto quello che è descritto qui sono la documentazione Test Workflow e la pagina dedicata a Test Action per le integrazioni.
L’ordine conta: trigger con esempio salvato, poi Test Action sui singoli passi, poi il workflow intero con Enroll a contact. Invertire la sequenza ti dà meno informazioni, non di più. E il contatto interno — creato prima di tutto il resto — è l’unica guardia che impedisce che un test diventi un messaggio indesiderato nella casella di qualcuno che non stavi cercando di raggiungere.
Domande frequenti
Devo testare il workflow prima di pubblicarlo?
No, GoHighLevel non lo richiede. Puoi pubblicare senza aver mai avviato un test. Il test serve a te, non alla piattaforma: un workflow non testato in produzione esegue con la stessa certezza, nel bene e nel male.
Posso testare senza far scattare un evento reale?
Sì. Con Enroll a contact forzi l’ingresso di un contatto nel workflow senza aspettare che l’evento trigger si verifichi. È il modo più veloce per testare flussi che dipendono da form, tag o campi aggiornati.
Dove rivedo le prove già eseguite?
Nel tab History dell’editor del workflow. Puoi filtrare per Success, Failed o Skipped e rilanciare qualsiasi run precedente con Retry run, usando gli stessi dati della prova originale.
Perché il pulsante Test Action è grigio?
Tre cause possibili: l’account dell’app esterna non è collegato, manca un campo obbligatorio nel passo, oppure il trigger non ha ancora un esempio di dati salvato. La terza è la più frequente: testa prima il trigger con Test using events o Enroll a contact.
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.
