HighLevel introduce nuovi custom fields: URL controllati, date flessibili, utenti e campi visuali

TL;DR: HighLevel ha annunciato un ampliamento dei custom fields che introduce campi URL con controllo dei domini, campi data e ora configurabili, campi per associare uno o più utenti a un record, immagini o icone nelle opzioni di radio button e checkbox, oltre ai campi rich text. Per agenzie, team commerciali e aziende che lavorano in GoHighLevel, l’impatto è una raccolta dati potenzialmente più coerente e più adatta a processi specifici. La fonte non dettaglia il percorso nell’interfaccia né la disponibilità effettiva per ogni piano, account o area del prodotto.

In sintesi

Il cambiamento riguarda qualità, struttura e leggibilità dei dati raccolti in HighLevel. I nuovi custom fields consentono di modellare con maggiore precisione le informazioni presenti nei record: non soltanto testo libero e selezioni standard, ma URL sottoposti a regole, date limitate da vincoli, assegnazioni a membri del team e opzioni accompagnate da elementi visuali.

L’annuncio ufficiale, pubblicato da HighLevel il 16 settembre 2026, parla di un’espansione pensata per rendere più flessibile il modo in cui le aziende acquisiscono, organizzano e gestiscono le informazioni. La novità può interessare CRM, moduli, processi di presa in carico, rinnovi, richieste commerciali e flussi operativi basati su dati personalizzati.

La fonte ufficiale è il changelog di HighLevel: Introducing new custom fields. Nomi delle funzioni, collocazione nell’interfaccia e disponibilità possono cambiare dopo la data di verifica indicata nella fonte.

Cosa cambia nei custom fields di HighLevel

HighLevel aggiunge sei gruppi di capacità ai campi personalizzati, con controlli più puntuali sull’input e nuove modalità di visualizzazione. Non si tratta di un singolo campo, ma di un aggiornamento che interviene su raccolta, validazione e consultazione dei dati.

La prima novità è costituita dai campi URL dedicati. Invece di utilizzare genericamente un campo di testo per un sito web, un profilo o una risorsa online, sarà possibile raccogliere indirizzi web in un formato strutturato. La configurazione citata da HighLevel permette inoltre di accettare tutti i domini, autorizzare solo domini specifici oppure bloccarne alcuni.

La seconda area riguarda data e ora. I campi possono essere impostati come data e ora, sola data oppure solo ora. HighLevel indica anche la possibilità di limitare le date selezionabili al futuro, al passato o a un intervallo specifico.

Il terzo tipo è il campo Users, destinato ad associare uno o più utenti al record. Secondo il changelog, gli utenti assegnati tramite questo campo ricevono anche accesso a livello follower. È un dettaglio rilevante: il campo non opera esclusivamente come etichetta organizzativa, ma può avere conseguenze sull’accesso e sul coinvolgimento dei membri del team.

Completano il pacchetto le immagini o icone per le opzioni dei radio button, le immagini per le opzioni delle checkbox e i campi rich text, con formattazioni quali grassetto, corsivo, titoli, liste e altre opzioni non specificate nel dettaglio.

A chi servono URL con controllo dei domini e date con vincoli

Questi campi sono utili quando un dato deve rispettare regole operative, non essere soltanto registrato. Agenzie e aziende possono così avvicinare la struttura dei campi alla logica reale del proprio servizio.

Un campo URL con whitelist o blocklist di domini può essere pertinente, ad esempio, per raccogliere link a profili social, pagine di siti dei clienti, documentazione, risorse di onboarding o pagine di campagne. Se un processo richiede collegamenti provenienti da fonti definite, il controllo del dominio può ridurre l’inserimento di indirizzi non allineati alla procedura.

La fonte non spiega come HighLevel gestisca tecnicamente ogni variazione possibile di URL, sottodomini o parametri. Prima di costruire processi dipendenti da questa validazione, è quindi opportuno verificare il comportamento nel proprio ambiente e con i domini effettivamente utilizzati.

I campi data e ora flessibili possono invece adattarsi a casi come data di rinnovo, data di nascita, giorno di un evento, disponibilità di contatto o orario preferito. Il vincolo su date future, passate o comprese in un range è utile quando il valore ammesso non è indifferente: una data di rinnovo prevista può richiedere logiche diverse da una data storica o da una finestra di prenotazione.

Questa evoluzione è coerente con altri interventi di HighLevel sulla qualità della configurazione. Per esempio, la piattaforma ha introdotto un controllo che impedisce la pubblicazione di workflow con errori di configurazione: come funziona il validation gate dei workflow. In entrambi i casi, la direzione pratica è ridurre ambiguità e problemi prima che incidano sull’operatività.

Come funzionano i campi Users e cosa comporta l’accesso follower

Il campo Users permette di collegare direttamente le persone responsabili a un record e, secondo HighLevel, assegna loro accesso follower. Può risultare utile quando più figure collaborano sulla stessa opportunità, cliente, attività o pratica.

Un’agenzia può usare un campo di questo tipo per indicare account manager, referente per l’onboarding, responsabile operativo o altri membri del team. Un’azienda con un processo commerciale articolato può invece associare venditore, consulente e figura di delivery allo stesso record, evitando che l’informazione resti confinata in una nota non strutturata.

L’accesso follower merita attenzione prima dell’adozione su larga scala. La fonte afferma che gli utenti selezionati nel campo ricevono questo livello di accesso, ma non descrive tutte le implicazioni rispetto a ruoli, permessi, notifiche o impostazioni di privacy già presenti nel sub-account. Non è quindi corretto assumere che il campo sostituisca l’intera politica di autorizzazioni dell’organizzazione.

La pratica più prudente è definire prima chi dovrebbe essere associato ai record, quali informazioni può vedere e in quali processi l’assegnazione debba avvenire. Poi conviene effettuare test controllati, specialmente se i record includono dati commerciali, operativi o personali.

Perché immagini e icone possono migliorare radio button e checkbox

Le opzioni visuali aiutano a distinguere scelte che sono più riconoscibili attraverso un’immagine che tramite una sola etichetta testuale. HighLevel consente di aggiungere immagini o icone alle singole opzioni dei radio button; per le checkbox, l’annuncio cita l’aggiunta di un’immagine a ogni opzione.

Il radio button resta adatto ai casi in cui l’utente deve selezionare una sola alternativa. Se le alternative rappresentano stili, prodotti, design, categorie o varianti visive, un’icona o un’immagine può diminuire l’ambiguità della scelta. Le checkbox sono invece adatte alla selezione multipla e possono beneficiare della stessa logica quando l’utente deve riconoscere più elementi.

Il vantaggio non deriva automaticamente dalla presenza di immagini. Un set con creatività incoerenti, file poco leggibili o etichette generiche può rendere il campo più confuso. È consigliabile mantenere comunque una descrizione testuale chiara, usare asset coerenti e verificare che il significato dell’opzione rimanga comprensibile anche senza affidarsi esclusivamente alla componente visiva.

Per organizzazioni che progettano moduli con logiche più articolate, è utile considerare anche l’estensione delle condizioni ai servizi e noleggi: HighLevel estende la logica condizionale dei moduli a Services & Rentals. Le due novità rispondono a esigenze differenti, ma possono convivere: una migliora il tipo di input disponibile, l’altra può incidere su quando determinate sezioni di un modulo vengono mostrate.

Cosa permettono i campi rich text

Il rich text consente di memorizzare informazioni dettagliate in una forma più leggibile rispetto al testo semplice. HighLevel cita esplicitamente grassetto, corsivo, titoli, liste e altre possibilità di formattazione.

Questo tipo di campo può essere utile per briefing, richieste strutturate, informazioni di contesto, istruzioni interne o note che devono essere consultate da più persone. Titoli e liste possono rendere più facilmente scansionabile un contenuto lungo, soprattutto quando un record passa tra marketing, vendita, assistenza e operations.

Resta però importante non usare un campo rich text come sostituto universale dei dati strutturati. Una data di rinnovo, un URL di un sito, un utente responsabile o una categoria necessaria a segmentazioni e processi dovrebbero, dove possibile, mantenere un campo dedicato. Il rich text è più adatto al contesto descrittivo; i campi specifici servono a preservare consistenza e regole dell’informazione.

Quali errori evitare nell’adozione dei nuovi campi

Il rischio principale è aggiungere complessità senza una precisa finalità di processo. Più tipi di campo non significano necessariamente un CRM più ordinato.

Un primo errore è creare controlli sui domini senza aver definito quali domini siano realmente necessari. Una whitelist troppo rigida può ostacolare l’inserimento di link legittimi; una blocklist insufficiente potrebbe non risolvere il problema che si intendeva prevenire.

Il secondo errore è scegliere limiti temporali non coerenti con il dato. Impostare date future per informazioni storiche, o un intervallo troppo ristretto per richieste che arrivano con anticipo variabile, può impedire la raccolta di dati validi.

Il terzo è assegnare utenti tramite il nuovo campo senza valutare l’effetto dell’accesso follower indicato da HighLevel. La responsabilità operativa e la visibilità dei record vanno progettate insieme.

Il quarto è trasformare campi visuali in gallerie poco accessibili o poco chiare. Immagini e icone devono facilitare una scelta, non nascondere il significato dell’opzione. Infine, concentrare informazioni che devono essere filtrate o riutilizzate in un solo campo rich text rende più difficile standardizzare i processi in seguito.

Cosa verificare prima di aggiornare moduli e processi

Prima di modificare campi esistenti, conviene mappare quali dati alimentano automazioni, report, integrazioni e procedure interne. La fonte annuncia le funzioni, ma non fornisce istruzioni operative dettagliate su migrazioni, compatibilità retroattiva, utilizzo in tutte le superfici del prodotto o comportamento nei workflow.

Per questa ragione, un approccio graduale è preferibile: individuare un caso d’uso, configurare il campo secondo le opzioni disponibili nell’account, verificare i permessi nel caso dei Users fields e controllare come il dato viene visualizzato o utilizzato nei processi già attivi. Se un campo alimenta automazioni, modifiche e test dovrebbero tenere conto delle regole già configurate.

Le agenzie che distribuiscono configurazioni replicabili nei sub-account dovrebbero inoltre coordinare l’aggiornamento con la propria strategia di snapshot. HighLevel ha recentemente previsto protezioni per le personalizzazioni dei sub-account durante l’applicazione degli snapshot: i dettagli sulla protezione delle personalizzazioni. Non è una documentazione specifica dei nuovi custom fields, ma è un contesto utile quando una modifica di struttura dati deve essere distribuita senza sovrascrivere scelte locali.

In definitiva, l’annuncio rafforza i custom fields di HighLevel come strumento per tradurre esigenze di business in dati più ordinati: URL governati da regole, date coerenti, responsabilità esplicite, scelte visuali e note formattate. Il risultato operativo dipenderà dalla qualità del modello dati e dalle verifiche effettuate nel singolo account.

Per approfondire l’uso di HighLevel nelle comunicazioni con i contatti, puoi consultare il bonus WhatsApp per GoHighLevel. Valuta sempre impostazioni, permessi e flussi sul tuo caso concreto: risultati e impatto operativo variano in base al contesto.