Guida ai trigger HighLevel: scegliere l’evento giusto per ogni workflow

TL;DR: un trigger è l’evento che avvia un workflow in HighLevel; un’azione è ciò che il workflow esegue dopo. Per scegliere bene, occorre partire dal fatto che si verifica davvero — invio di un form, cambio di stato di un appuntamento, pagamento ricevuto, spostamento in pipeline — e usare il trigger che lo rappresenta direttamente. Il risultato operativo verificabile è un workflow che parte da un evento definito e coerente con il processo, anziché da una sua imitazione.

In sintesi

Un responsabile apre HighLevel al mattino e trova contatti nuovi, appuntamenti riprogrammati, trattative spostate in pipeline, risposte ai messaggi e pagamenti. Se ogni controllo dipende da una lettura manuale del CRM, il problema non è soltanto il tempo impiegato: diventa difficile capire quale attività debba iniziare, per chi e in seguito a quale evento.

La documentazione ufficiale di HighLevel definisce i trigger come gli eventi che danno avvio ai workflow e le azioni come i passaggi successivi eseguiti dal workflow. L’ordine è cronologico: prima accade l’evento intercettato dal trigger, poi il workflow esegue le azioni configurate.

Questa guida serve a chi gestisce processi commerciali, appuntamenti, comunicazioni, pagamenti, corsi, e-commerce o campagne in GoHighLevel. Non propone di automatizzare qualsiasi cosa: aiuta a riconoscere l’evento sorgente corretto, a evitare workaround inutili e a mantenere il flusso comprensibile anche quando cresce.

I nomi dei trigger e la loro disponibilità possono cambiare dopo la data di verifica della fonte. Per l’elenco di riferimento va consultata la guida ufficiale di HighLevel, A List of Workflow Triggers.

La situazione di partenza

Risposta breve: il processo manuale si inceppa quando un’azione dipende da un evento che nessuno intercetta con continuità.

Immaginiamo uno scenario ipotetico: un team raccoglie richieste da un form, gestisce appuntamenti e aggiorna opportunità commerciali. Senza una logica chiara, può far partire una sequenza quando viene applicato un tag, anche se il fatto davvero rilevante era l’invio del form; oppure aggiornare un campo di contatto per “segnalare” un pagamento, quando il sistema dispone di un evento di pagamento.

Sono scorciatoie comprensibili. Chi costruisce un workflow spesso parte dall’azione che vorrebbe ottenere — inviare una notifica, assegnare un task, cambiare una fase — e cerca poi un qualunque segnale per avviarla. Tuttavia, il segnale scelto può non coincidere con il processo reale.

Le conseguenze sono operative:

• il workflow è più difficile da spiegare a chi lo deve mantenere;
• un aggiornamento manuale diventa necessario solo per far partire un’automazione;
• diventa meno immediato distinguere l’origine di una comunicazione o di un task;
• più workflow possono dipendere dallo stesso tag o dallo stesso campo usato come espediente;
• verificare perché un flusso sia partito richiede di ricostruire passaggi non essenziali.

Il punto non è che tag, campi e webhook siano strumenti sbagliati. Sono trigger ufficialmente disponibili in contesti precisi. Il problema nasce quando vengono usati per simulare un evento che HighLevel può già rilevare direttamente, come un appuntamento annullato, un’opportunità diventata inattiva o un ordine inviato.

Cosa cambia con HighLevel

Risposta breve: HighLevel organizza gli eventi di avvio per area funzionale, così il workflow può partire dal dato che descrive realmente il processo.

Nel Workflow Builder, la fonte ufficiale indica che i trigger sono selezionabili da “add a trigger” e organizzati in categorie. Le categorie elencate sono: Contact Events, Appointments, Opportunities, Affiliate, Courses, Payments, Ecommerce Stores, IVR, Facebook/Instagram Events, Communities, Certificates, Communication e Google Ads.

Questa struttura chiarisce una relazione importante: HighLevel è la piattaforma che ospita il Workflow Builder; il trigger è lo strumento che ascolta un evento; il settore determina quali eventi sono utili; il risultato operativo è l’avvio di una sequenza in risposta a quell’evento.

Per esempio, in un processo di acquisizione lead, possono essere pertinenti Form Submitted, Facebook Lead Form Submitted, TikTok Form Submitted, LinkedIn Lead Form Submitted o Google Lead Form Submitted, a seconda dell’origine reale del contatto. Per una panoramica applicata alla presa in carico, vedi Nuovo lead in HighLevel: notifica interna e SLA di presa in carico del commerciale.

Nella gestione degli appuntamenti, la fonte distingue Appointment Status, che si attiva sui cambi di stato come booked, rescheduled, canceled o no-show, da Customer Booked Appointment, che si attiva quando il cliente prenota. Sono eventi vicini, ma non equivalenti: il primo segue uno stato, il secondo la prenotazione del cliente. Analogamente, Service Booking e Rental Booking riguardano rispettivamente prenotazioni tramite Services (v2) e prenotazioni di noleggio.

Per il commerciale, HighLevel elenca Opportunity Created, Opportunity Changed, Opportunity Status Changed, Pipeline Stage Changed e Stale Opportunities. Un’opportunità ferma non è la stessa cosa di un’opportunità spostata di fase: scegliere il trigger dedicato evita di confondere l’inattività con una modifica di pipeline. Il tema è approfondito in Opportunità ferme in HighLevel: workflow, task ed escalation senza inseguimenti manuali.

Anche l’area pagamenti ha eventi propri: Invoice, Payment Received, Order Form Submission, Order Submitted, Documents & Contracts, Estimates, Subscription, Refund e vari eventi sui coupon. Se il requisito è reagire a un pagamento acquisito con successo, la fonte indica Payment Received; non è necessario trasformare quell’informazione in un tag per rappresentarla nel workflow.

Tra gli altri eventi disponibili figurano risposte del cliente su canali connessi (Customer Replied), eventi email come consegna, apertura, clic, rimbalzo, spam o disiscrizione (Email Events), chiamate con dettagli o esiti selezionati (Call Details), webhook in ingresso (Inbound Webhook) ed esecuzioni pianificate senza contatto (Scheduler).

Come configurare il flusso

Risposta breve: si parte dall’evento osservabile, si verifica il dato disponibile e solo dopo si definiscono le azioni in ordine cronologico.

La fonte ufficiale descrive il punto di accesso: in Workflows si seleziona “add a trigger”, quindi si apre il menu dei trigger. L’interfaccia può cambiare; per questo i passaggi sotto sono un metodo editoriale di progettazione basato sulle categorie e sulle descrizioni ufficiali, non una verifica della UI attuale.

1. Scrivi l’evento in linguaggio operativo. Non partire da “devo mandare un messaggio”, ma da “il contatto ha inviato il form”, “l’appuntamento è stato segnato no-show” oppure “l’opportunità soddisfa la regola di inattività”. Questa frase riduce l’ambiguità prima ancora della configurazione.

2. Individua l’area che possiede il dato. Un form appartiene agli eventi di comunicazione/ingresso elencati nella fonte; una fase è nell’area Opportunities; lo stato di una prenotazione è in Appointments; un incasso è in Payments. La categoria non è un dettaglio di navigazione: è un indizio sulla sorgente dell’evento.

3. Scegli il trigger più specifico disponibile. Se il workflow deve iniziare all’invio di un modulo HighLevel, il riferimento è Form Submitted. Se deve iniziare quando cambia un campo contatto definito, il riferimento è Contact Changed. Se deve iniziare all’aggiunta o rimozione di un tag selezionato, è Contact Tag. La specificità rende chiaro perché il flusso parte.

4. Usa filtri e condizioni indicati dal trigger quando sono rilevanti. La fonte segnala, ad esempio, che Contact Changed si attiva quando specifici campi assumono valori definiti e che Appointment Status riguarda cambi di stato. Per New Affiliate Sales indica filtri facoltativi per affiliate, campagna, stato del metodo di pagamento e stato del modulo fiscale. Non bisogna però dare per scontato che ogni trigger esponga gli stessi filtri o gli stessi dati.

5. Definisci le azioni successive come conseguenza dell’evento. Dopo il trigger possono seguire le azioni previste dal processo: notifiche interne, task, aggiornamenti o comunicazioni, se configurati nel workflow. La documentazione stabilisce la distinzione funzionale: il trigger inizia, l’azione esegue.

6. Mantieni separati i casi con significato diverso. Un workflow per chi prenota e uno per chi entra in no-show possono avere finalità diverse perché partono da eventi diversi. Nel caso di recupero no-show, il riferimento utile è Centro estetico: recupero no-show senza continuare messaggi inutili.

7. Documenta la scelta. Un consiglio editoriale semplice è annotare nel nome o nella documentazione interna: evento sorgente, eventuale filtro e obiettivo della sequenza. Non cambia il funzionamento tecnico, ma evita che un tag o un campo usato in un workflow venga modificato senza conoscerne le dipendenze.

Ci sono casi in cui un trigger generico è appropriato. Inbound Webhook è pensato per dati ricevuti all’URL webhook del workflow; Custom Trigger serve a eventi personalizzati per casi non standard; Scheduler è un evento temporale senza necessità di un contatto. Qui non si sta simulando un evento: si sta usando il meccanismo previsto dalla fonte per una sorgente esterna, un evento definito dall’utente o una cadenza temporale.

Il risultato operativo

Risposta breve: il risultato controllabile è sapere quale evento ha avviato il workflow e quale sequenza deve seguirne.

Un workflow ben impostato non promette automaticamente più vendite, meno assenze o tempi di risposta specifici: tali risultati dipendono dal contesto, dalle azioni configurate e dal processo del team. Ciò che è verificabile è un’altra cosa: quando si verifica l’evento selezionato, il workflow può essere avviato secondo la logica descritta dal trigger.

In pratica, la scelta corretta crea una catena leggibile:

• un form inviato avvia il flusso di acquisizione;
• un cambio di stato dell’appuntamento avvia il flusso coerente con quel cambio;
• una fase pipeline cambiata avvia il flusso commerciale relativo alla fase;
• un pagamento ricevuto avvia il flusso successivo all’incasso;
• un evento email o una risposta del cliente avvia un flusso di comunicazione pertinente.

Questa separazione è utile in molti settori senza attribuire risultati a clienti reali. Un’attività locale può distinguere prenotazione, annullamento e no-show. Un’agenzia può distinguere form inviato e avanzamento dell’opportunità. Un progetto formativo può usare eventi quali Lesson Started, Lesson Completed, Product Started, Product Completed, User Login o Certificates Issued, tutti presenti nell’elenco ufficiale.

L’obiettivo non è costruire più automazioni, ma rendere ogni workflow proporzionato al fatto che lo origina.

Errori e limiti

Risposta breve: non tutti gli eventi sono intercambiabili e la presenza di un trigger non sostituisce la definizione del processo.

Il primo errore è simulare un evento già disponibile. Per esempio, usare Contact Tag per imitare un cambio di fase, oppure usare Contact Changed per imitare un pagamento ricevuto, aggiunge un passaggio che può essere evitato quando il dato sorgente ha un trigger dedicato.

Il secondo è usare un trigger troppo ampio. Customer Replied copre la risposta del contatto su qualsiasi canale connesso, secondo la fonte; non equivale necessariamente a un evento email specifico. Se il requisito riguarda consegna, apertura, clic, bounce, spam o unsubscribe, la categoria corretta è Email Events.

Il terzo è confondere creazione, modifica e stato. Un nuovo contatto è Contact Created; una modifica di campi selezionati è Contact Changed; l’attivazione o disattivazione del Do Not Disturb è Contact DND. Lo stesso ragionamento vale per Opportunity Created, Opportunity Changed e Opportunity Status Changed.

Il quarto è ignorare i trigger legati al tempo. Contact Birthday Reminder e Custom Date Reminder lavorano rispetto a date e offset; Task Reminder si attiva al raggiungimento dell’orario di promemoria; Scheduler opera su una pianificazione senza contatto. Non sono sostituti l’uno dell’altro. La fonte specifica inoltre che i campi supportati da Custom Date Reminder dipendono dal tipo di workflow e possono includere campi Contact, campi data Opportunity nei workflow basati su contatto, Custom Object o Company.

Infine, non conviene dedurre disponibilità o comportamento oltre ciò che la documentazione dichiara. Alcuni trigger Shopify legacy risultano indicati come “Deprecating Soon” nella fonte, inclusi Shopify Abandoned Cart e Shopify Order Fulfilled. Per store con connessioni correnti, l’elenco riporta anche Order Fulfilled e Abandoned Checkout. Prima di basare un processo critico su una voce specifica, va quindi ricontrollata la documentazione ufficiale.

Se il problema iniziale è non sapere cosa richieda attenzione ogni giorno, la risposta non è far partire un workflow da qualsiasi segnale disponibile. È collegare ogni automazione all’evento reale che il team intende gestire. Per altri spunti pratici sull’uso di HighLevel, puoi consultare il bonus WhatsApp GoHighLevel. I risultati variano in base al contesto, alla configurazione e al processo operativo adottato.