HighLevel introduce i campi personalizzati condizionali per le opportunità

TL;DR: HighLevel ha annunciato i Conditional Custom Fields for Opportunities, una funzione che consente agli amministratori di adattare i moduli delle opportunità alle caratteristiche di ciascun deal. Le regole possono mostrare campi o cartelle e rendere obbligatori determinati dati in base a pipeline, stage, stato dell’opportunità o valori di specifici campi. La novità punta a rendere più ordinata la raccolta dati commerciale, ma richiede una progettazione accurata: le validazioni non si applicano agli aggiornamenti effettuati via Public API o workflow.

In sintesi

HighLevel amplia la gestione delle opportunità con regole condizionali applicate ai campi personalizzati. Secondo il changelog ufficiale, gli admin possono decidere quali campi, cartelle di campi e requisiti di compilazione debbano entrare in gioco in funzione del contesto del deal.

Il principio è semplice: non tutti i dati sono rilevanti in ogni momento del processo commerciale. Una trattativa appena entrata in pipeline può richiedere poche informazioni essenziali; una trattativa in fase di proposta, verifica o chiusura può invece richiedere campi ulteriori, come la tipologia di servizio, documenti, motivazione della perdita o dettagli operativi. Con i Conditional Custom Fields for Opportunities, HighLevel permette di modellare questa progressione direttamente nel form dell’opportunità.

La fonte ufficiale indica che le condizioni possono usare pipeline, pipeline stage, status e valori di campi di tipo dropdown, radio, checkbox e multi-select. Le regole possono essere singole oppure composte con logica AND/OR. L’esito selezionabile è uno tra mostrare un campo, mostrare una cartella oppure rendere un campo obbligatorio.

L’annuncio riguarda i flussi di aggiunta, modifica e modifica massiva delle opportunità, sia sul web sia su mobile. I nomi delle voci, la disponibilità effettiva e l’interfaccia possono cambiare dopo la data di verifica riportata dalla fonte ufficiale, l’11 agosto 2026.

Cosa cambia nella gestione delle opportunity

Fino a quando non viene configurata una regola, non cambia nulla: la documentazione precisa infatti che le opportunità mantengono il comportamento esistente fino alla creazione della prima regola da parte di un amministratore. Questo dettaglio è importante per account, agenzie e team che vogliono pianificare l’adozione senza modificare subito i processi in uso.

Quando invece una regola di visibilità viene applicata, campi e cartelle inclusi nell’azione Show restano nascosti fino a quando le condizioni non risultano soddisfatte. I campi non inclusi in una regola Show continuano invece a essere visibili normalmente. In altre parole, la funzione non nasconde automaticamente tutti i campi: agisce soltanto sugli elementi espressamente inclusi nella configurazione condizionale.

L’altro cambiamento rilevante riguarda l’obbligatorietà. Un campo reso mandatory attraverso una regola deve essere completato affinché l’opportunità possa essere salvata, quando la condizione corrispondente è attiva. Se più regole rendono obbligatori dei campi, i requisiti si sommano. Non va quindi interpretato il sistema come una scelta tra regole alternative: più condizioni contemporaneamente vere possono aumentare l’elenco dei dati richiesti.

Questa impostazione può rendere più rigorosa la raccolta delle informazioni, soprattutto per processi di vendita con più team, pipeline differenziate o controlli richiesti prima del passaggio a uno stage successivo. È un’evoluzione coerente con l’attenzione di HighLevel verso gli strumenti dedicati alle opportunità, dopo l’introduzione del contact overlay per opportunità e appuntamenti, che punta a rendere più accessibile il contesto del contatto durante il lavoro sul deal.

A chi serve questa novità

I campi condizionali sulle opportunità possono essere utili in particolare a quattro tipologie di utenti.

Agenzie e account multi-cliente. Le regole vengono configurate separatamente per ogni sub-account. Questo consente di adattare il modello ai processi di ogni cliente, ma comporta anche che una configurazione creata in un sub-account non debba essere data per automaticamente disponibile negli altri.

Team commerciali con pipeline complesse. Chi gestisce preventivi, qualifiche, contratti, onboarding o rinnovi può mostrare informazioni solo quando sono effettivamente pertinenti allo stage e allo stato dell’opportunità. Il risultato atteso è un form meno dispersivo per gli operatori e una maggiore coerenza nel CRM.

Aziende che puntano su report più affidabili. La fonte collega esplicitamente la novità al miglioramento di accuratezza e consistenza del reporting. Se un valore importante viene richiesto nel momento corretto, diminuisce il rischio di opportunity incomplete o categorizzate in modo non uniforme.

Processi con raccolta dati standardizzata. In presenza di più venditori o sedi, le regole possono aiutare a far emergere gli stessi campi in condizioni equivalenti. Resta però fondamentale definire a monte cosa debba essere raccolto, da chi e con quale criterio: la funzione applica la logica definita dagli admin, non sostituisce la governance del processo.

Come funzionano le regole secondo HighLevel

Il changelog ufficiale descrive un percorso di attivazione e configurazione. Per iniziare, occorre andare in Settings → Labs e abilitare, per il sub-account, l’opzione chiamata Show & Require Opportunity Fields Conditionally.

Successivamente, il percorso indicato è Settings → Custom Fields → Opportunity → Conditional Rules. Da qui un amministratore può selezionare Create conditional rule, scegliere i trigger e collegarli con logica AND/OR. I trigger disponibili indicati dalla fonte sono pipeline, stage della pipeline, status, dropdown, radio button, checkbox e multi-select.

Dopo la definizione della condizione, va selezionato l’esito desiderato:

• mostrare un singolo campo;
• mostrare una cartella;
• rendere obbligatorio un campo.

HighLevel segnala inoltre la presenza di una live preview prima del salvataggio della regola. Dopo la revisione, la procedura descritta prevede il salvataggio; la fonte afferma che le regole possono essere attivate subito dopo il salvataggio.

Esiste anche un percorso alternativo collegato alle pipeline: in Settings → Opportunities & Pipelines, aprendo il menu Actions di una pipeline o di uno stage, è possibile selezionare Manage conditional rules. Poiché layout e denominazioni possono evolvere, è prudente considerare questi percorsi come quelli comunicati da HighLevel alla data della nota, non come istruzioni immutabili per ogni account.

La gestione delle regole è riservata agli Admin: solo loro possono crearle, modificarle o eliminarle. Chi lavora sul deal, invece, incontra l’effetto delle regole nei flussi di Add, Edit e Bulk Edit su web e mobile.

Benefici concreti per CRM, vendite e operations

Il primo beneficio è la riduzione del rumore nei form. Se un campo non è rilevante per una data pipeline, stage o combinazione di valori, può restare fuori dalla vista fino al momento opportuno. Questo non equivale necessariamente a un form più breve in assoluto, ma a un form contestuale.

Il secondo è una migliore qualità del dato. Rendere obbligatori i dettagli nel punto corretto del processo può evitare che un’opportunità avanzi senza le informazioni minime necessarie. Può trattarsi, ad esempio, di una classificazione commerciale, di un dato necessario al passaggio di consegne o di un motivo di esito: gli esempi dipendono dalla configurazione scelta dal team.

Il terzo è la possibilità di standardizzare senza appesantire. Un’unica struttura di custom field può servire percorsi diversi, purché le regole siano costruite in modo chiaro. Ciò è potenzialmente utile quando pipeline e stage hanno bisogni informativi differenti ma convivono nello stesso sub-account.

Infine, la compatibilità dichiarata con Bulk Edit può risultare utile per chi gestisce grandi volumi di opportunity. Tuttavia, prima di cambiare in massa record esistenti è opportuno valutare quali regole obbligatorie possano attivarsi e se i dati storici siano completi.

Limiti e aspetti da non sottovalutare

Il limite più importante dichiarato dalla fonte riguarda l’ambito della validazione: il controllo al salvataggio viene applicato sul web e su mobile, ma non agli aggiornamenti eseguiti tramite Public API o tramite workflow. Di conseguenza, non è corretto affidarsi a queste regole come unico presidio di qualità se il sub-account aggiorna opportunità automaticamente o tramite integrazioni esterne.

In tali scenari, occorre progettare anche la logica di origine: workflow, integrazioni e sistemi che inviano dati via API dovrebbero fornire le informazioni richieste dal processo, perché la convalida descritta per il form non interviene su quegli aggiornamenti.

Un secondo aspetto è l’effetto cumulativo delle regole mandatory. Se più condizioni risultano vere, tutti i relativi obblighi si combinano. Regole troppo numerose, sovrapposte o poco documentate possono quindi rendere il salvataggio inatteso o difficile per gli utenti.

Va considerata anche la separazione per sub-account. Per le agenzie, ciò può significare replicare e verificare la configurazione per ogni ambiente cliente. La novità non deve quindi essere letta come una regola globale automaticamente ereditata da tutti i sub-account.

Errori da evitare nella configurazione

Un primo errore è rendere obbligatori campi che non vengono mostrati dalla stessa logica o che non sono chiaramente raggiungibili nel contesto operativo. La documentazione distingue tra esiti Show e Make mandatory; nella progettazione è utile controllare che l’utente possa effettivamente vedere e compilare ciò che gli viene richiesto.

Il secondo è usare logiche AND/OR senza un disegno esplicito. Un AND restringe le circostanze di attivazione, mentre un OR le amplia. Prima del salvataggio, la live preview indicata da HighLevel è il passaggio da usare per controllare il risultato previsto della regola.

Il terzo è ignorare la sovrapposizione tra regole. Poiché i requisiti obbligatori si sommano, una matrice che elenchi trigger, campi mostrati e campi obbligatori per pipeline e stage può prevenire ambiguità.

Il quarto è assumere che le integrazioni siano bloccate dalle validazioni del form. Public API e workflow-based updates non rientrano nella validazione dichiarata. È opportuno allineare chi cura CRM, automazioni e integrazioni prima di imporre nuovi campi obbligatori.

Infine, evitare di trattare le regole come un sostituto della formazione interna. La funzionalità può guidare la compilazione, ma definizioni come “deal qualificato”, “documentazione completa” o “motivo di perdita” devono restare condivise dal team.

Fonte ufficiale e prossimi passi

Tutti i dettagli di questa news derivano dal changelog Conditional Custom Fields for Opportunities pubblicato da HighLevel. La fonte presenta la funzionalità come configurabile dagli Admin a livello di sub-account e utilizzabile nei flussi di aggiunta, modifica e modifica massiva delle opportunity su web e mobile.

Per chi sta strutturando o aggiornando una pipeline, il passo più sensato è mappare prima le informazioni davvero necessarie per ogni fase, poi trasformarle in poche regole comprensibili e controllarne l’effetto in anteprima. Chi utilizza anche importazioni e sistemi CRM esterni può inoltre considerare come si inserisce questa novità nel proprio stack: per esempio, l’importazione diretta da HubSpot per contatti, deal, pipeline e attività rende ancora più importante stabilire standard coerenti per i dati che arrivano o vengono aggiornati da fonti differenti.

Se stai valutando HighLevel per centralizzare processi commerciali e comunicazioni, puoi approfondire il bonus WhatsApp GoHighLevel. Ogni configurazione va comunque adattata al contesto operativo: risultati, qualità del dato e adozione da parte del team possono variare in base a processi, integrazioni e modalità d’uso.