HighLevel migliora i Dynamic Value Chips: errori distinti tra valori mancanti e valori inesistenti

TL;DR: HighLevel aggiorna i Dynamic Value Chips nei workflow introducendo un terzo stato visivo. Oltre al blu per i valori disponibili e al rosso per quelli inesistenti, compare il giallo: segnala un valore reale della piattaforma che non riceve dati dal workflow aperto. L'obiettivo è rendere più chiari gli errori di configurazione senza bloccare i casi intenzionali, come i valori passati tra workflow. Secondo HighLevel, la modifica riguarda l'interfaccia: la risoluzione dei valori continua ad avvenire in fase di esecuzione come in precedenza.

In sintesi

HighLevel separa gli errori reali dalle dipendenze mancanti nel contesto del singolo workflow. Per agenzie, consulenti e team che costruiscono automazioni articolate, questo aggiornamento riduce l'ambiguità nella lettura dei campi dinamici inseriti in azioni, messaggi e note.

La fonte ufficiale, pubblicata il 4 settembre 2026, descrive un cambiamento nella segnalazione dei Dynamic Value Chips, cioè i riferimenti dinamici racchiusi tra doppie parentesi graffe, come {{contact.first_name}}. In passato un chip era essenzialmente riconosciuto oppure non riconosciuto: se il builder non riusciva a risolverlo nel workflow in modifica, veniva mostrato in rosso con un messaggio assimilabile a “value not recognized”.

Ora HighLevel usa tre stati:

• Blu: il valore è disponibile nel workflow e può essere popolato dal flusso;
• Giallo: il valore esiste nella piattaforma, ma nel workflow aperto non c'è una fonte che lo fornisca;
• Rosso: il valore non esiste sulla piattaforma e richiede una correzione.

La distinzione è importante soprattutto quando un'automazione riceve dati da un'altra automazione, oppure quando usa un riferimento valido che dipende da un trigger o da uno step non presente nel canvas corrente. In questi scenari, il precedente indicatore rosso poteva far apparire errata una configurazione voluta.

Per dettagli e formulazione originale, il riferimento è il changelog ufficiale di HighLevel: Improved: Dynamic Value Chips with Improved error segmentation.

Che cosa cambia nei Dynamic Value Chips di HighLevel?

Cambia il significato del colore: il rosso identifica un riferimento non valido, il giallo una fonte assente nel workflow aperto. Non si tratta, secondo la fonte, di una modifica alla logica con cui i valori vengono elaborati quando l'automazione viene eseguita.

Un chip blu indica che il workflow può compilare quel dato. La fonte può essere il record del contatto, un valore di sistema — per esempio la data corrente — oppure un'informazione ottenuta in uno step precedente.

Un chip giallo, invece, segnala che il token è riconosciuto da HighLevel ma non è alimentato dal workflow in esame. L'esempio fornito nel changelog è {{sheet.10.rowNumber}} all'interno di un workflow che non contiene uno step Google Sheets. Il valore, in quel contesto, viene renderizzato vuoto, salvo il caso in cui venga passato da un altro workflow attraverso Add to Workflow con i parametri di input del trigger (pass input trigger parameters).

Il rosso resta il segnale su cui intervenire. Se viene inserito {{applesheet.10.rowNumber}}, HighLevel non trova un valore corrispondente nella piattaforma: nessun workflow potrà quindi valorizzarlo. Lo stesso vale per un errore di battitura come {{contact.frist_name}} al posto di un campo contatto corretto.

Per chi è utile la nuova segmentazione degli errori?

L'aggiornamento è particolarmente utile a chi gestisce workflow modulari, automazioni multi-step e passaggi di dati tra flussi diversi. Il beneficio non è l'aggiunta di nuovi dati dinamici, ma una diagnosi visiva più precisa durante la configurazione.

Le agenzie che lavorano su più sub-account, i team CRM e gli specialisti di marketing automation possono incontrare frequentemente valori non presenti nel flusso locale ma disponibili in una catena di automazioni più ampia. Un workflow può, ad esempio, ricevere parametri da un altro workflow tramite Add to Workflow; in quel caso un valore giallo non implica automaticamente che la configurazione sia inutilizzabile.

Questo caso è coerente con workflow che integrano fonti esterne o dati recuperati prima di un'azione successiva. In un processo basato su webhook, per esempio, identificare correttamente il record prima di usare i suoi campi riduce le incoerenze del flusso: approfondisci nella guida su Find Contact in HighLevel per collegare un webhook al contatto corretto.

La novità può risultare utile anche per chi sviluppa workflow attivati da eventi della piattaforma. HighLevel ha recentemente esteso il trigger “User login” al nuovo Client Portal: quando trigger, fonti dati e azioni evolvono, distinguere un token inesistente da un token valido ma non disponibile nel singolo canvas aiuta a leggere meglio le dipendenze.

Come interpretare blu, giallo e rosso prima di pubblicare un workflow?

Il blu conferma la disponibilità nel flusso, il giallo richiede una verifica del percorso dei dati, il rosso richiede la correzione del valore. Questa è la regola pratica più utile emersa dal changelog.

Prima di salvare o pubblicare, conviene valutare ciascun colore nel suo contesto:

1. Chip blu: verificare che il dato selezionato sia effettivamente quello desiderato per l'azione. Il colore indica disponibilità, non la correttezza strategica del contenuto o della segmentazione.
2. Chip giallo: controllare se il valore debba arrivare da uno step precedente, da un trigger appropriato oppure da un workflow chiamante. Se l'architettura prevede il passaggio tramite Add to Workflow e parametri di input, il giallo può essere intenzionale.
3. Chip rosso: controllare spelling, prefisso dell'entità e sintassi del riferimento. Qui il messaggio è netto: il valore non trova corrispondenza nella piattaforma.

HighLevel specifica inoltre che il giallo è un avviso e non un blocco. È quindi possibile salvare e pubblicare il workflow come di consueto. Questa possibilità non va però interpretata come garanzia che il dato sarà disponibile in ogni esecuzione: se nessuna fonte lo fornisce, il valore verrà reso vuoto secondo quanto riportato nella fonte.

Perché la modifica è rilevante per workflow, CRM e comunicazioni?

Un dato dinamico errato può produrre contenuti incompleti; un dato valido ma condizionale richiede invece una progettazione consapevole del flusso. La nuova interfaccia aiuta a separare i due problemi.

In HighLevel, i valori dinamici possono essere usati per personalizzare messaggi, aggiornare note, comporre URL e trasferire informazioni tra azioni. Un riferimento a una fattura, come {{invoice.url}}, può essere valido sulla piattaforma ma non essere generato da un workflow che non parte da un trigger relativo alle fatture. In precedenza, il rosso poteva suggerire che il valore fosse sconosciuto; con lo stato giallo, HighLevel comunica invece che il riferimento è reale ma manca la sua sorgente nel flusso attuale.

Il risultato operativo atteso è una fase di debugging più leggibile: meno tempo speso a sostituire token validi solo perché il builder non li vede alimentati in quel momento, e più attenzione sui riferimenti che non possono funzionare in nessuna circostanza.

La precisione dei dati a monte resta essenziale anche nelle automazioni email. Se un workflow deve reagire a un'azione specifica, è utile verificare che trigger ed eventi siano coerenti: la guida Email Events in HighLevel: attivare un follow-up soltanto dopo un clic affronta proprio questa progettazione condizionale.

La normalizzazione degli spazi nelle parentesi graffe evita falsi errori?

Sì: HighLevel dichiara che gli spazi interni alle doppie parentesi graffe non influiscono più sul riconoscimento del valore. È un intervento mirato a eliminare falsi negativi legati alla formattazione.

La fonte cita il valore Attribution URL, memorizzato dalla piattaforma nella forma {{ attribution.first.url }} con spazi. In precedenza, digitare {{attribution.first.url}} senza spazi poteva far apparire il chip in rosso. Con l'aggiornamento, entrambe le versioni corrispondono.

Questo non elimina la necessità di usare il nome corretto dell'entità e del campo. La tolleranza riguarda gli spazi nella sintassi delle parentesi graffe, non corregge errori come frist_name, né rende disponibili dati che il workflow non riceve.

Quali errori evitare con i nuovi chip gialli e rossi?

L'errore più comune sarà trattare il giallo come un via libera assoluto o il rosso come un semplice warning. I due stati richiedono comportamenti diversi.

Da evitare:

• pubblicare un workflow con chip gialli senza aver verificato il percorso con cui il dato dovrebbe essere fornito;
• presumere che un token valido venga compilato automaticamente in ogni trigger o ramo dell'automazione;
• ignorare un chip rosso pensando che possa essere valorizzato da un altro workflow: secondo HighLevel, un riferimento rosso non esiste sulla piattaforma;
• confondere la disponibilità tecnica di un campo con la qualità del dato memorizzato nel CRM;
• modificare token validi solo perché non sono blu nel workflow corrente, senza prima controllare se vengono passati come parametri di input.

La fonte chiarisce che l'aggiornamento è limitato alla UI. I valori continuano a risolversi al momento dell'esecuzione come avveniva prima; di conseguenza, le automazioni che funzionavano prima della modifica continuano a funzionare secondo la stessa logica descritta da HighLevel.

Cosa non cambia nella risoluzione dei valori?

Non cambia il momento in cui HighLevel prova a valorizzare i campi: la risoluzione resta legata all'esecuzione del workflow. Il nuovo schema cromatico migliora la diagnosi nell'editor, ma non trasforma un valore assente in un dato disponibile.

Questo limite è centrale: il colore non sostituisce i test funzionali sulle diverse condizioni di ingresso, sui rami e sui workflow chiamanti. Il giallo offre un'informazione più accurata rispetto al vecchio rosso generalizzato, ma l'implementazione deve continuare a prevedere fonti dati, trigger e passaggi tra automazioni coerenti con l'obiettivo.

Nomi delle funzionalità, comportamenti dell'interfaccia e disponibilità possono cambiare dopo la data di verifica indicata dalla fonte ufficiale, il 4 settembre 2026. Per configurazioni rilevanti conviene quindi consultare il changelog collegato e testare il flusso nel proprio contesto.

Per ricevere risorse e approfondimenti pratici sull'uso di GoHighLevel, puoi consultare il nostro bonus WhatsApp per GoHighLevel. Ogni risultato dipende dalla struttura del workflow, dalla qualità dei dati e dal contesto operativo dell'account.

FAQ

I chip gialli bloccano la pubblicazione di un workflow HighLevel?

No. La fonte ufficiale afferma che il giallo è un avviso, non un blocco: il workflow può essere salvato e pubblicato normalmente.

Che cosa significa un Dynamic Value Chip rosso?

Significa che il valore non esiste sulla piattaforma. Occorre verificare sintassi, typo e nome del campo, perché nessun workflow potrà valorizzare un riferimento inesistente.

Un chip giallo verrà compilato automaticamente durante l'esecuzione?

Non necessariamente. Il valore è valido, ma nel workflow aperto non c'è una fonte che lo alimenti. Può essere valorizzato se arriva, per esempio, da un altro workflow tramite Add to Workflow con parametri di input del trigger.

Gli spazi in {{ valore }} e {{valore}} fanno differenza?

Secondo l'aggiornamento, no: gli spazi interni alle parentesi graffe non incidono più sul riconoscimento. Questo non corregge però nomi di campi errati.

Questa modifica altera le automazioni già attive?

No, secondo HighLevel è una modifica della UI. I valori continuano a risolversi in fase di esecuzione come prima e ciò che funzionava in precedenza continua a seguire la stessa logica.