Workflow GoHighLevel: caricare snapshot senza duplicati

TL;DR: quando un’agenzia carica uno snapshot in un nuovo sottoconto, il problema non è solo trasferire un workflow: è verificare che l’automazione venga creata una sola volta e resti utilizzabile. HighLevel ha annunciato una correzione per i duplicati causati da richieste simultanee di caricamento. Il risultato operativo verificabile è più semplice: dopo il caricamento, il sottoconto dovrebbe contenere un solo workflow per la stessa origine e destinazione, senza una copia bloccata in stato “Processing”.

In sintesi

La correzione interessa HighLevel e i workflow caricati tramite snapshot in una nuova location, cioè un sottoconto. Secondo l’annuncio ufficiale, il problema precedente poteva generare due workflow anziché uno quando arrivavano richieste simultanee di caricamento: un workflow completava l’operazione, mentre l’altro poteva restare in “Processing”.

L’aggiornamento introduce dei blocchi, o locks, che impediscono richieste ridondanti per la stessa origine e destinazione. È un cambiamento utile soprattutto ad agenzie italiane, aziende con più sottoconti e modelli SaaS che usano gli snapshot per replicare configurazioni e standardizzare l’onboarding.

Questa guida distingue ciò che HighLevel dichiara ufficialmente dai consigli editoriali di controllo. Non descrive clic o percorsi dell’interfaccia non presenti nella fonte: nomi di funzioni, schermate e disponibilità possono cambiare dopo la data di verifica della fonte, 8 maggio 2026.

La situazione di partenza

Risposta breve: il processo manuale diventa fragile quando uno snapshot deve creare automazioni coerenti in più sottoconti.

Il titolare di un’agenzia o il responsabile operativo conosce bene la situazione: è necessario preparare un nuovo sottoconto con processi già definiti, ad esempio workflow per email marketing, follow-up dei lead o attività commerciali. Lo snapshot serve proprio a replicare una configurazione senza ricostruirla da zero.

In uno scenario ipotetico, dichiarato come tale, un’agenzia può usare lo stesso snapshot per rendere omogenei i flussi di onboarding dei propri clienti. Il vantaggio atteso non è “fare tutto automaticamente” senza controlli, ma avere una base replicabile tra location diverse. Se però il caricamento crea una copia aggiuntiva del workflow, il sottoconto perde chiarezza proprio nel momento in cui dovrebbe essere pronto per l’uso.

La fonte ufficiale descrive il difetto: in determinate circostanze, richieste multiple e simultanee di caricamento potevano produrre due workflow. Uno si completava correttamente; l’altro restava bloccato in stato “Processing”. La conseguenza pratica era un intervento manuale per identificare e ripulire workflow duplicati o non completati.

Per un team che gestisce molti sottoconti, questo passaggio manuale introduce tre problemi operativi:

• diventa meno immediato capire quale workflow sia quello da utilizzare;
• aumenta il tempo speso a verificare automazioni e stati di elaborazione;
• la standardizzazione tramite snapshot può lasciare elementi ridondanti nell’ambiente del cliente.

Non è necessario attribuire questi effetti a un caso cliente specifico per riconoscere il rischio: sono la diretta conseguenza del comportamento descritto da HighLevel. Il problema riguarda quindi la relazione tra snapshot, workflow e sottoconto: lo snapshot replica la configurazione, il workflow esegue l’automazione, il sottoconto è l’ambiente in cui quella configurazione deve restare ordinata.

Cosa cambia con HighLevel

Risposta breve: HighLevel dichiara di bloccare le richieste ridondanti, così che la stessa operazione di snapshot crei un solo workflow per la medesima origine e destinazione.

Nel changelog ufficiale di HighLevel, la piattaforma comunica di aver risolto il bug relativo alla creazione di workflow duplicati da snapshot. La soluzione indicata è l’implementazione di locks: blocchi pensati per intercettare e impedire caricamenti concorrenti o ridondanti.

Questo è il passaggio ufficiale più importante da trattenere: la correzione non viene presentata come una nuova modalità di progettare workflow, né come una garanzia generale contro ogni possibile duplicazione presente in un account. Riguarda in modo specifico la generazione accidentale di duplicati durante il caricamento del workflow da snapshot, per la stessa coppia origine-destinazione.

Per chi usa GoHighLevel in agenzia, il cambiamento rende più affidabile un’operazione ricorrente: distribuire processi standard in più location. Per una PMI che gestisce internamente un sottoconto, il beneficio è una maggiore pulizia dell’elenco delle automazioni e una minore probabilità di trovare una copia inutilizzabile in “Processing”.

Dal punto di vista editoriale, la correzione non sostituisce una procedura interna. Riduce il rischio tecnico descritto dalla fonte, ma un team dovrebbe continuare a sapere quale snapshot è stato applicato, a quale sottoconto e con quale finalità. Questa tracciabilità rende più facile distinguere un’anomalia di caricamento da due workflow che il team ha creato intenzionalmente per esigenze diverse.

Se la configurazione replica email e oggetti personalizzati, può essere utile affiancare questo controllo alla nostra guida sui workflow email in HighLevel per aziende e oggetti personalizzati. La correzione degli snapshot evita duplicazioni nel deployment; la struttura del workflow resta comunque una responsabilità progettuale dell’account.

Come configurare il flusso

Risposta breve: la fonte conferma la correzione nel caricamento da snapshot, ma non pubblica una sequenza di clic; il flusso più prudente è caricare, attendere l’esito e verificare che nel sottoconto esista una sola automazione prevista.

È importante separare i fatti dalle indicazioni editoriali. HighLevel comunica che i blocchi agiscono quando un workflow viene caricato da snapshot e che la finalità è creare un solo workflow per la stessa origine e destinazione. La fonte non specifica quali comandi usare nell’interfaccia, come creare uno snapshot o quali eventuali messaggi siano visualizzati. Per questo non sarebbe corretto trasformare quei dettagli in istruzioni certe.

Passaggi supportati dalla fonte ufficiale

1. Usare uno snapshot per caricare una configurazione in una nuova location o sottoconto.
2. Considerare che il sistema aggiornato applica blocchi alle richieste ridondanti relative al caricamento di workflow dalla stessa origine verso la stessa destinazione.
3. Attendere il completamento dell’operazione e verificare il risultato nel sottoconto: per il caso coperto dalla correzione, l’esito previsto è un’unica automazione, non due copie di cui una in “Processing”.

Checklist editoriale prima e dopo il caricamento

I punti seguenti non sono funzionalità dichiarate nel changelog; sono consigli operativi per rendere controllabile il processo.

Prima del caricamento, definire quale snapshot deve essere applicato e quale sottoconto ne è destinatario. Annotare internamente data, responsabile e scopo del deployment evita che attività ripetute da persone diverse vengano confuse con un errore tecnico. Non serve aggiungere una procedura complessa: basta poter rispondere alla domanda “quale configurazione stiamo distribuendo e dove?”.

Durante il caricamento, evitare di trattare l’operazione come se richiedesse tentativi simultanei. La fonte identifica proprio nelle richieste multiple e contemporanee la causa del problema corretto. Il nuovo sistema è progettato per bloccarle, ma mantenere un’esecuzione ordinata resta una buona pratica organizzativa, non una promessa su ogni condizione possibile.

Dopo il caricamento, controllare l’elenco dei workflow del sottoconto rispetto alla configurazione attesa. Il controllo è concreto: cercare una sola automazione corrispondente al workflow trasferito e verificare che non sia presente una copia aggiuntiva in stato “Processing”. Se il team rileva duplicati già esistenti, il changelog non spiega come rimuoverli né afferma che la correzione li pulisca retroattivamente; occorre quindi applicare le procedure di gestione appropriate al proprio account.

Per workflow con ramificazioni e condizioni, la prevenzione dei duplicati non basta a validare la logica. La guida su come ottimizzare i workflow con AI Builder If/Else può aiutare a ragionare sulla struttura delle condizioni, senza confondere quel tema con il caricamento via snapshot.

Il risultato operativo

Risposta breve: il risultato da verificare è un sottoconto più ordinato, con un solo workflow creato dal caricamento previsto e senza la seconda copia bloccata in “Processing”.

L’aggiornamento di HighLevel non promette risultati commerciali, conversioni o risparmi quantificati. Il risultato dichiarato è tecnico e operativo: prevenire automazioni ridondanti nate da richieste simultanee di caricamento da snapshot, migliorando la coerenza del deployment.

Per un’agenzia, questo significa poter usare gli snapshot come strumento di standardizzazione con meno attività manuali dedicate alla pulizia di duplicati. Per un’azienda che usa HighLevel per marketing o vendite, significa avere un ambiente di lavoro più leggibile quando i workflow vengono replicati in una nuova location.

La verifica deve restare semplice e ripetibile: confrontare ciò che era previsto nello snapshot con ciò che compare nel sottoconto dopo il caricamento. Se il workflow atteso è uno, l’esito operativo coerente con la correzione è uno solo. Questa verifica è più utile di un’assunzione basata sul fatto che l’aggiornamento sia stato annunciato.

Quando le automazioni gestiscono comunicazioni o follow-up, l’ordine nel sottoconto aiuta anche chi deve intervenire in seguito sulla configurazione. Se il processo usa conversazioni WhatsApp, vale la stessa cautela: la stabilità del workflow è importante, ma messaggi, consenso e strategia restano elementi da governare nel contesto specifico.

Errori e limiti

Risposta breve: non attribuire alla correzione capacità che la fonte non dichiara e non scambiare l’assenza di duplicati per una verifica completa dell’automazione.

Il primo errore è leggere il fix come una garanzia assoluta per ogni duplicazione possibile in GoHighLevel. La fonte circoscrive il problema ai workflow creati da snapshot in presenza di richieste multiple e simultanee. Workflow duplicati per ragioni diverse non rientrano automaticamente nella descrizione dell’aggiornamento.

Il secondo errore è presumere che un workflow non duplicato sia anche corretto in ogni sua parte. Il changelog parla di creazione e stato dei workflow, non di contenuti, trigger, condizioni, email, integrazioni o risultati delle campagne. Dopo il deployment, la verifica dell’unicità va quindi distinta dalla revisione funzionale del flusso.

Il terzo errore è inventare una procedura UI basandosi solo sul nome della funzione. La fonte non pubblica un percorso di menu, pulsanti, permessi richiesti o tempistiche di elaborazione. L’interfaccia, i nomi e la disponibilità delle funzioni possono cambiare dopo l’8 maggio 2026: per dettagli aggiornati, fare riferimento alla documentazione e al changelog ufficiali.

Infine, evitare di caricare sugli snapshot aspettative estranee allo strumento. Uno snapshot è utile per replicare configurazioni; non sostituisce la definizione del processo del cliente, il controllo delle automazioni né la valutazione dei risultati. Tornando al problema iniziale, l’obiettivo non è aggiungere un altro controllo manuale: è rendere quel controllo breve, chiaro e mirato a confermare che il sottoconto contenga l’unico workflow atteso.

Se stai impostando follow-up e conversazioni con WhatsApp in HighLevel, puoi approfondire le opzioni disponibili nella pagina bonus WhatsApp GoHighLevel. Valuta sempre il flusso sul tuo contesto operativo: i risultati variano in base al contesto, all’impegno e al modello di business.