Anche i campi sono architettura

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 6 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Scegli l’oggetto giusto · Successivo: Le relazioni hanno conseguenze

La domanda a cui risponde questo modulo: Come dovrebbe Salesforce rappresentare fisicamente ogni dato?

Creare un campo richiede circa un minuto. Nuovo campo, scegli un tipo, dagli un nome, Avanti, Avanti, Salva. È esattamente per questo che i campi non vengono trattati come architettura.

Entra in una org che esiste da dieci anni e apri Account. Cinquecento campi. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Tre numeri cliente diversi. Una casella di controllo che nessuno eliminerà perché nessuno sa quale integrazione la usa ancora. Creare il campo ha richiesto un minuto. Conviverci richiede anni. Quindi l’idea di questo modulo è semplice: un campo è una decisione architetturale. Non sempre grande, ma ogni campo codifica qualcosa sul significato, il comportamento, l’identità o la qualità dei dati, e come gli oggetti, i campi sono facili da aggiungere e sorprendentemente difficili da togliere.

Cosa significano davvero questi dati?

Nel capitolo 2 abbiamo dato attributi alle nostre entità: una Consegna ha una fascia oraria pianificata, un Camion ha un VIN. Ora li implementiamo, ed è qui che si salta subito a “campo di testo”. Aspetta. Prima del tipo voglio sapere cosa significano i dati. È un numero, o un identificatore che per caso contiene cifre? Una data, o un momento nel tempo? Testo libero, o un valore di un insieme approvato? Inserito da una persona, o di proprietà di un altro sistema? Può cambiare? Deve essere unico? Può mancare? Va memorizzato, o calcolato? Non sono domande da Imposta. Sono domande di architettura dei dati, e il tipo di campo viene dopo aver risposto.

Un numero non è sempre un numero

Steve Trucking dà a ogni camion un numero di flotta, diciamo 001247. Campo numerico? Probabilmente no. Sommiamo i numeri di flotta? Il camion 1247 meno il camion 1246 fa un camion? È un identificatore che per caso contiene cifre, e un campo Numero eliminerebbe perfino gli zeri iniziali. Lo stesso vale per codici postali, codici prodotto, numeri di conto e numeri di tracciamento. L’aspetto del valore non ti dice cosa significa. Scegli il tipo per il comportamento che ti serve, non per l’aspetto dei dati di esempio.

Una persona ha bisogno di identificarlo?

Ogni oggetto personalizzato riceve un campo Name, e la prima decisione è testo o numerazione automatica. Mi chiedo: una persona ha bisogno di identificare questa cosa? Le persone conoscono un Partner retail per nome e un camion per il suo numero di flotta. Ma un manifesto di carico che il sistema genera ogni notte? Nessuno dovrebbe digitare “Manifesto 10-02 numero 3” perché Salesforce richiedeva un Name. Dagli una numerazione automatica. Solo, non confondere quel Name generato con l’identità del record: la numerazione automatica aiuta gli utenti, l’ID Salesforce identifica il record, e il riferimento del manifesto del Partner retail può identificare la stessa cosa tra i sistemi. Tre lavori diversi.

La schermata dei dettagli

Scegli un tipo, fai clic su Avanti, e Imposta ti chiede i dettagli. È la schermata in cui si prendono davvero la maggior parte delle decisioni di questo modulo, di solito di fretta.

Nuovo campo personalizzato, passaggio 2: i dettagli (schermata, 2026-10-12). Dimensione intera

Due caselle si somigliano e fanno lavori diversi. Descrizione è per le persone che gestiscono la org, e ora per gli strumenti di IA che la leggono: cosa significa il campo, chi ne è responsabile, da dove viene. Testo della Guida è per l’utente sullo schermo: cosa scrivere qui. Compilale entrambe. Poi vengono Obbligatorio, Univoco e ID esterno, e ognuno merita una sezione a sé. Sotto, il Valore predefinito può essere una formula, così un nuovo record può partire da un valore sensato invece che da un vuoto.

Obbligatorio è una decisione più grande di quanto sembri

Nella procedura guidata dei campi c’è una piccola casella chiamata Obbligatorio, e come abbiamo visto nel capitolo 1, può essere una bomba a orologeria. Hai un oggetto da cinque anni con due milioni di record, e ora qualcuno decide che un nuovo campo deve avere sempre un valore. E i due milioni di record che lo precedono? Le integrazioni che non lo inviano? L’automazione che crea il record prima che il valore sia noto? Il processo in cui il valore salta fuori solo tre passaggi dopo?

“Obbligatorio” sembra una decisione sulla qualità dei dati, e a volte lo è. Ma quando un valore diventa noto fa parte del processo di business. Quindi non spuntare Obbligatorio perché qualcuno dice “lo vogliamo sempre”. Chiediti quando è noto, chi lo fornisce e cosa succede quando non c’è. Lo metteremo sulla scala completa della coerenza nel modulo 7.

Anche unico significa qualcosa

Se segno un campo come unico, faccio un’affermazione sul business: non “di solito non si ripete”, ma “due record non possono mai avere questo valore”. È forte. E la schermata ti fa decidere un’altra cosa: “ABC” e “abc” sono lo stesso valore o due valori diversi? Senza distinzione tra maiuscole e minuscole è l’impostazione più sicura per qualsiasi cosa digiti una persona. Qui vale la regola delle chiavi del capitolo 2, unica, immutabile, priva di significato, mai un dato personale. Se qualcuno mi dice che l’email del dipendente è unica, comincio a chiedere: può cambiare, qualcuno può andarsene e tornare, gli indirizzi possono essere riutilizzati, cosa succede dopo un’acquisizione? L’email può essere utile, perfino unica oggi. Non ne fa una buona identità.

ID esterni: l’identità oltre il confine

È qui che gli ID esterni si guadagnano il loro posto. La schermata lo descrive bene: il campo diventa “l’identificatore univoco del record proveniente da un sistema esterno”. L’ERP ha il cliente 873492; Salesforce ha il proprio ID del record. Quando l’ERP invia un aggiornamento, come sappiamo a quale record appartiene? Segna un campo come ID esterno e un’integrazione può fare un upsert su di esso: crea il record se non esiste, lo aggiorna se esiste (Upsert a Record Using an External ID (opens in a new tab)). E quando carichi record figli, puoi indicare il padre tramite il suo ID esterno invece di cercare prima l’ID Salesforce. Mi piace dire che lasci fare a Salesforce la ricerca per te. Molto potente.

Nota che il numero dell’ERP non diventa l’identità del record Salesforce. È un attributo, e un record può portarne diversi: un ID cliente dell’ERP, un ID legacy, l’ID di un partner. Va bene. Un’entità di business può essere conosciuta in modo diverso da diversi sistemi. La domanda architetturale è quale sistema possiede ogni identificatore, e quale promessa fa: segnalo come unico solo se il business lo garantisce davvero.

Tipo di campo per tipo di campo

Ora i tipi stessi. Apri Nuovo campo su qualsiasi oggetto e Imposta ti mostra l’intero elenco, raggruppato nel modo in cui lo percorrerò: i campi che Salesforce calcola per te, i campi di relazione, e poi i tipi di dati.

Imposta, Nuovo campo personalizzato, passaggio 1: i tipi di dati (schermata, 2026-10-12). Dimensione intera

Ecco l’intero elenco a colpo d’occhio, con l’unica cosa che vorrei ricordassi di ciascuno.

Gruppo	Tipo	Da ricordare
Calcolati	Numerazione automatica	Fino a 30 caratteri, 20 dei quali per prefisso o suffisso; un’etichetta per le persone, non l’identità del record
	Formula	Calcolata quando viene letta, non memorizzata; 3.900 caratteri
	Riepilogo roll-up	Conteggio, somma, minimo o massimo dei dettagli; solo master-dettaglio
Relazioni	Ricerca, master-dettaglio, ricerca esterna	Modulo 7
Dati	Casella di controllo	Vero o falso, con un valore predefinito che scegli tu; nei flussi può comunque comparire null
	Numero, Percentuale, Valuta	Regole di arrotondamento; zeri iniziali eliminati; 15 cifre decimali
	Data, Data/ora, Ora	Un giorno, un momento o un’ora del giorno; i momenti sono memorizzati in UTC
	Email, Telefono, URL	Formattati e controllati al salvataggio: 80, 40 e 255 caratteri
	Geolocalizzazione, Indirizzo	Campi composti che costano più di un campo: 3 e 9
	Elenco di selezione, selezione multipla	Un vocabolario controllato, di cui è responsabile un amministratore
	Testo, Area di testo, lunga, RTF, crittografato	Fino a 255 sul record e indicizzabile; oltre, niente indice né filtri

I campi che Salesforce calcola

La numerazione automatica assegna a ogni nuovo record il numero successivo di una sequenza, in un formato che definisci tu, come T-{000000}. Usala quando una persona ha bisogno di un riferimento comodo e nessuno dovrebbe doverselo inventare. L’intero valore arriva a 30 caratteri, e 20 di questi sono riservati al prefisso o al suffisso. Ricorda solo dal capitolo 2: è un’etichetta per le persone, non l’identità del record, e i numeri non sono sempre strettamente consecutivi.

I campi formula calcolano un valore a partire da altri campi. Sono potenti, e vengono calcolati quando il record viene letto, non quando viene salvato, quindi non c’è nulla di memorizzato che possa diventare obsoleto. Scegli tu cosa restituisce la formula: una casella di controllo, una valuta, una data, una data/ora, un numero, una percentuale, un testo o un’ora.

Nuovo campo personalizzato, formula: la scelta del tipo restituito (schermata, 2026-10-12). Dimensione intera

Poi scrivi la formula vera e propria, con campi, operatori e funzioni, e ne controlli la sintassi. Nota il pulsante Use Formula Assistant: ora l’IA di Salesforce ti aiuta a scrivere la formula. Usalo, e poi leggi cosa ha scritto. La formula è tua, non dell’assistente.

L’editor delle formule, con il Formula Assistant (schermata, 2026-10-12). Dimensione intera Una formula può arrivare a 3.900 caratteri, e non può superare i 15.000 byte quando viene salvata o compilata; una formula lunga si può dividere in più campi formula che si richiamano a vicenda. Le aree di testo lunghe, i campi crittografati e i campi Descrizione non si possono usare nelle formule.

I campi di riepilogo roll-up stanno sul master e contano, sommano, o prendono il minimo o il massimo dei suoi record di dettaglio. Funzionano solo attraverso una relazione master-dettaglio, che è uno dei motivi principali per scegliere la master-dettaglio. Ci torneremo, insieme ai loro limiti, nel modulo 7.

Memorizzato o derivato?

Abbiamo davvero bisogno di memorizzare questo valore? Se ho quantità e prezzo unitario, qualcuno, o qualche automazione, deve mantenere un totale? Forse dovrebbe derivarlo una formula: un’unica fonte per il calcolo, ricalcolato quando viene letto, quindi cambi la quantità e la risposta segue. Le formule hanno i loro limiti (dimensione al salvataggio e lunghezza visualizzata; Formula Field Limits and Restrictions (opens in a new tab)), e quelle complesse diventano difficili da mantenere.

Ma a volte il business non vuole la risposta di oggi. Vuole la risposta com’era. Se la regola dello sconto cambia l’anno prossimo, la fattura dell’anno scorso deve improvvisamente mostrare un importo diverso? Certo che no. Quindi la domanda non è “Salesforce può calcolarlo?”. È “è un calcolo attuale o un fatto storico?”. I fatti storici si memorizzano.

I campi di relazione

Anche le relazioni di ricerca, master-dettaglio e di ricerca esterna sono campi, ed è lì che le linee del tuo modello diventano reali. La relazione di ricerca è il legame lasco; la master-dettaglio lega la vita, la titolarità e la sicurezza del figlio al padre; la ricerca esterna raggiunge un oggetto esterno del modulo 4, con la corrispondenza sul suo ID esterno. Scegliere tra loro è una decisione abbastanza grande da meritare un modulo tutto suo.

Casella di controllo

Una casella di controllo è il campo più semplice che ci sia: vero o falso, selezionata o non selezionata. È perfetta per un fatto sì/no sul record: È attivo, Installazione richiesta, Firmato alla consegna. Quando ne crei una, Salesforce ti fa scegliere il suo valore predefinito, selezionata o non selezionata, ed è una vera decisione: è il valore con cui parte ogni nuovo record, compresi i record che un’integrazione crea senza inviare il campo. Report e visualizzazioni elenco la filtrano come Vero e Falso; gli strumenti di importazione e l’esportazione settimanale la mostrano come 1 e 0.

Una trappola da conoscere. Il campo sul record ha due valori, ma l’automazione intorno può averne un terzo. In un flusso, una variabile casella di controllo mai impostata è null, non falso, e salvarla su un record non riesce (Trailblazer Community (opens in a new tab); vedi anche il problema noto di Salesforce W-11208535 (opens in a new tab)). Scegli un valore predefinito sensato, e fai in modo che flussi e codice trattino il null di proposito.

Numero, Percentuale e Valuta

Numero memorizza un numero reale, ed elimina gli zeri iniziali, ed è esattamente per questo che un numero di flotta come 001247 non è un Numero. Salesforce arrotonda i campi numerici per eccesso in valore assoluto quando la cifra è 5 (half away from zero): 12,345 diventa 12,35, e −12,345 diventa −12,35. E nei campi unione arrotonda secondo le impostazioni locali dell’utente, non secondo le cifre decimali che hai impostato sul campo.

Percentuale memorizza un decimale e mostra una percentuale: inserisci 0,10 e vedi 10%. I valori perdono precisione dopo 15 cifre decimali.

Valuta è formattata per il denaro, e in una org con più valute porta con sé il codice della valuta e può usare i tassi di cambio; con la gestione avanzata delle valute (opens in a new tab), le opportunità possono usare tassi di cambio datati, il tasso del periodo in cui la trattativa si è chiusa. Solo le opportunità e ciò che le circonda (prodotti, pianificazioni, ripartizioni e i relativi report) usano i tassi datati; i campi valuta sugli altri oggetti mantengono l’unico tasso statico. Attenzione all’arrotondamento: senza cifre decimali, Salesforce semplicemente tronca (23,5 diventa 23); con una o più, arrotonda per eccesso in valore assoluto quando la cifra è 5.

Data, Data/ora e Ora

Tre tipi, tre significati diversi. Una Data è un giorno: un contratto scade in una data. Una Data/ora è un momento: la consegna è arrivata alle 9:42 di quella mattina. Un’Ora è un’ora del giorno senza alcuna data: il negozio apre alle 7:00, tutti i giorni.

La trappola è il momento. Salesforce memorizza i valori data/ora in GMT (UTC). L’ora che un utente digita viene letta nel suo fuso orario, convertita e memorizzata; quando qualcuno la legge, viene convertita di nuovo nel fuso orario di chi legge. Il più delle volte è esattamente ciò che vuoi. Ma ecco l’esempio che faccio in aula: un coordinatore a Los Angeles registra una consegna tardi la domenica sera, alle 22 ora del Pacifico. Sotto, Salesforce ha memorizzato lunedì mattina, alle 5 GMT. Un report raggruppato per giorno in un altro fuso orario, o un’integrazione che legge il valore grezzo, può mettere quella consegna della domenica di lunedì. “Il giorno in cui è successo” dipende dall’orologio di chi lo chiedi. Tieni d’occhio i fusi orari degli utenti, e decidi quale intende il business.

E fai attenzione quando li confronti. Sotto, una data/ora è un unico grande numero: Apex la legge come il numero di millisecondi dal 1° gennaio 1970, 00:00:00 GMT (Datetime Class (opens in a new tab)). È un momento preciso, non un giorno. Quindi chiedere se due data/ora sono uguali (==) quasi mai fa ciò che vuoi: 9:42:00 e 9:42:01 non sono uguali, e non lo sono nemmeno “lunedì” e un qualsiasi momento di lunedì. Chiedi invece un intervallo: dall’inizio in poi (>=) e fino alla fine compresa (<=). “Ogni consegna di lunedì” è ogni consegna >= lunedì 00:00 e <= lunedì 23:59:59, nel fuso orario che hai deciso essere quello del business.

E una curiosità: Salesforce non può memorizzare una data qualsiasi. Le date valide vanno dal 1° gennaio 1700 al 31 dicembre 4000, e Salesforce indica lo stesso intervallo per le date e per le data/ora (Data Import Dates (opens in a new tab)). Anche gli estremi sono momenti in GMT, quindi per un utente nel fuso del Pacifico il primo valore valido sono le 16 del 31 dicembre 1699. La data di fondazione della tua società storica potrebbe non entrarci. E il classico trucco del “nessuna data di fine”, il 31 dicembre 9999, viene rifiutato; se ti serve un segnaposto in un futuro lontano, deve essere nell’anno 4000 o prima.

Email, Telefono e URL

Questi sono i campi formattati, e fanno più che memorizzare caratteri. Email contiene fino a 80 caratteri e ne viene controllato il formato; su contatti e lead, fare clic sul valore avvia un’email a quell’indirizzo. Telefono contiene fino a 40 caratteri, è formattato come numero di telefono e diventa click-to-dial quando la org ha un sistema telefonico collegato. URL contiene fino a 255 caratteri e si apre come link. È la piattaforma che ti dà un comportamento gratis, ed è per questo che non memorizzerei mai un numero di telefono in un semplice campo di testo.

Anche le integrazioni vengono controllate. Un valore che non rispetta il formato del campo, come un indirizzo email mal formato, non supera la convalida, e viene rifiutato l’intero record, non solo quel campo. Quindi quando i dati del sistema di origine sono disordinati, puliscili prima che arrivino, o metti in conto i record che non si caricheranno.

Geolocalizzazione e Indirizzo

Geolocalizzazione contiene una latitudine e una longitudine. Sotto, un campo chiamato Location__c è in realtà due valori che puoi leggere e impostare separatamente, Location__Latitude__s e Location__Longitude__s. E puoi interrogarlo: le funzioni DISTANCE e GEOLOCATION di SOQL trovano i record entro un raggio, o li ordinano in base alla distanza. “Ogni consegna aperta entro 25 miglia da questo camion” è una sola query: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Indirizzo contiene un indirizzo intero, via, città, stato o provincia, codice postale e paese, e gli utenti possono cercare un indirizzo e farsi compilare le parti.

Entrambi sono campi composti: un campo sullo schermo, diversi sotto. E costano più di un campo rispetto al limite del tuo oggetto: una Geolocalizzazione conta come tre campi personalizzati, e un Indirizzo come nove. Su un oggetto già affollato, conta.

Elenco di selezione e selezione multipla

Un elenco di selezione controlla cosa possono inserire gli utenti: un valore da un elenco che definisci tu. Lo stato? Elenco di selezione, probabilmente. Ma i valori sono metadati, e un amministratore deve aggiungerli o modificarli. Quindi chiedo comunque chi è responsabile dei valori, quanto spesso cambiano, se più oggetti hanno bisogno dello stesso elenco, se i valori portano informazioni proprie, e se il vocabolario appartiene a un altro sistema.

Anche dove vivono i valori è una decisione. Quando un elenco si usa una volta, su un solo campo, tieni i valori sul campo stesso, sull’oggetto; è ciò che Salesforce fa per impostazione predefinita. Ma quando lo stesso insieme di valori comincia a comparire in più posti, una Regione sull’account, sulla consegna e sul magazzino, promuovilo a set di valori globale prima che le copie divergano. Un set di valori globale mantiene un solo elenco per tutti, fino a 1.000 valori, attivi e inattivi insieme (Picklist Limitations (opens in a new tab)). La descrizione di Imposta dice perché conta: il set di valori “è limitato, quindi gli utenti non possono aggiungere valori non approvati tramite l’API”. Un elenco, un responsabile, e nessuna integrazione che fa entrare di nascosto una nuova grafia.

Quest’ultimo punto è la differenza tra con restrizioni e senza restrizioni. In un elenco di selezione con restrizioni sono ammessi solo i valori definiti da un amministratore, da qualsiasi parte arrivino: un utente, un’importazione o un’integrazione che invia altro riceve un errore, “bad value for restricted picklist field”, e il record non viene salvato. In un elenco di selezione senza restrizioni gli utenti scelgono comunque dall’elenco sullo schermo, ma l’API, le importazioni e l’automazione possono inviare qualsiasi valore, e Salesforce lo salva e lo aggiunge come valore inattivo (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). È così che una org finisce con “Consegnato”, “consegnato” e “Cnsgnt”. I set di valori globali sono sempre con restrizioni. La mia scelta predefinita è con restrizioni; senza restrizioni è una scelta deliberata per quando i valori appartengono davvero a un altro sistema, e allora qualcuno si occupa di ripulire quelli inattivi.

Imposta, Set di valori dell’elenco di selezione: un nuovo set di valori globale (schermata, 2026-10-12). Dimensione intera

Un elenco di selezione a selezione multipla permette a un utente di scegliere più valori, memorizzati insieme e separati da punti e virgola. Comodo su uno schermo, scomodo ovunque altrove: più difficile da filtrare, da usare nei report e da integrare, e non si può usare nel filtro di un riepilogo roll-up. Più valori per un record di solito significano la lezione del capitolo 2: c’è un oggetto figlio che cerca di uscire.

Un elenco di selezione ha anche un valore in più rispetto a quelli che hai definito: vuoto. Un record può restare senza nulla selezionato, e questo coglie in fallo molti. In una formula o in una regola di convalida non puoi verificare un elenco di selezione con ISBLANK da solo; scrivi ISBLANK(TEXT(Field__c)), oppure ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Quindi decidi cosa significa “nessun valore” per ogni elenco di selezione: è ammesso, e cosa significa quando succede? Poi fai in modo che formule, regole di convalida e filtri lo gestiscano.

E a volte un attributo è in realtà un’entità. Qualcuno chiede un elenco di selezione dei centri di distribuzione. Sono nove. Facile. Poi scopriamo che ognuno ha un indirizzo, un responsabile, degli orari, una capacità, una regione e dei camion. Quello non è un elenco di selezione; è una cosa. Non trasformare un’entità in un elenco di selezione solo perché per ora non sono molte. Sembra fantastico il primo anno e terribile il quinto. (Il modulo 5 del capitolo 2 contiene le mie regole pratiche per capire quando un elenco si merita un oggetto tutto suo.)

La famiglia dei testi

Insegno il testo come due tipi, e il confine tra i due è a 255 caratteri.

Fino a 255: memorizzato con il record. Testo contiene fino a 255 caratteri, e puoi usarlo quasi ovunque: in formule, filtri, report, visualizzazioni elenco, come campo univoco o come ID esterno, e può essere indicizzato. Anche Area di testo contiene 255 caratteri, su più righe, come una breve nota.

Oltre 255: memorizzato per riferimento. Area di testo (lunga) contiene fino a 131.072 caratteri, e Area di testo (RTF) contiene lo stesso con formattazione, link e immagini. Li immagino memorizzati da una parte, con il record che tiene un puntatore, e si comportano proprio così: nessun indice, quindi non puoi renderli univoci né ID esterni; non puoi filtrarli in una clausola WHERE di SOQL (SOQL WHERE (opens in a new tab)); le formule non possono usarli (Formula Field Limits and Restrictions (opens in a new tab)); e i report mostrano solo i primi 254 caratteri di un campo personalizzato di questo tipo, con i filtri dei report che cercano solo nei primi 255 circa (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Le immagini caricate in un campo RTF possono arrivare a 1 MB ciascuna, e contano sullo spazio di archiviazione dei file, mentre il testo conta sullo spazio di archiviazione dei dati (Rich Text Area Field Considerations (opens in a new tab)). Quindi se qualcuno ha bisogno di cercare, ordinare, far corrispondere o usare nei report quel valore, tienilo sotto i 255 e tienilo un campo Testo.

Testo (crittografato) memorizza fino a 175 caratteri in forma crittografata, con la Classic Encryption. Se la tua org usa Shield Platform Encryption, crittografi invece un normale campo Testo, e in quel modo si possono crittografare anche molti altri tipi.

Dai una descrizione a ogni campo

Il mio standard: ogni campo riceve una descrizione. Ci credo da molto tempo, e nell’epoca dell’IA conta più che mai: ogni strumento di IA e ogni agente che legge la tua org legge le descrizioni per capire cosa significa un campo. Una descrizione vuota è un’ipotesi pronta a succedere. Cosa significa Customer_Status__c? Chi ne è responsabile? Da dove viene? Gli utenti possono modificarlo, o stanotte lo sovrascrive l’ERP? Fra sei mesi non me lo ricorderò, e fra tre anni l’amministratore che gestisce la org non lo saprà a meno che non glielo abbiamo detto. L’etichetta non è documentazione, e nemmeno il nome API.

Sugli oggetti molto condivisi (Account, Contatto, Opportunità) uso anche dei prefissi nei nomi per i campi specializzati, così la loro origine e il loro scopo si vedono nel nome stesso: per esempio, tutto ciò che possiede l’ERP inizia con lo stesso prefisso. Non cerco nomi API di dodici parole. Voglio che il modello si spieghi da solo.

Classifica ciò che conta: i campi della tassonomia

Salesforce dà a ogni campo un insieme di metadati di classificazione. Io li chiamo campi della tassonomia. Puoi registrare il responsabile dei dati (Data Owner); l’uso del campo (Field Usage: Active, DeprecateCandidate, Hidden); il livello di sensibilità dei dati (Data Sensitivity Level: Public, Internal, Confidential, Restricted, MissionCritical); e la categorizzazione di conformità (Compliance Categorization): PII, HIPAA, GDPR, PCI, CCPA e altre. Funzionano sui campi standard come su quelli personalizzati (Data Classification Metadata Fields (opens in a new tab)).

Perché farlo? Perché i processi possono leggerli. Segna un campo come GDPR e un processo può trovare ogni campo GDPR su un record e mascherarlo o rimuoverlo. E quando il trust layer di Salesforce invia un prompt a un modello linguistico di grandi dimensioni, può usare proprio questa classificazione per mascherare i campi sensibili: in uscita sostituisce il nome di un cliente, diciamo “Maria Lopez”, con un segnaposto, il modello non vede mai il nome, e in entrata il nome viene rimesso nella risposta (Einstein Trust Layer (opens in a new tab)).

Un aggiornamento. Salesforce ora documenta che il mascheramento basato su pattern e su campi per gli LLM è disattivato per gli agenti: il mascheramento può togliere il contesto di cui un agente ha bisogno per rispondere (Data Masking Limitations in Agentforce (opens in a new tab)). La classificazione guida ancora il mascheramento per le altre funzionalità di IA generativa, ma non contarci per tenere i dati personali lontani da un agente; è una decisione di accesso e di progettazione (capitolo 12).

La mia posizione: la classificazione è importante nei momenti chiave. Non trasformarla in tre settimane passate a compilare ogni casella perché lo ha detto la governance. Usala dove conta: dati personali, dati finanziari, dati regolamentati, e campi per cui il business ha bisogno di un responsabile con un nome. Il punto è che la sensibilità smette di essere conoscenza nella testa di qualcuno e diventa parte del campo.

Oltre l’esame: cosa cambia l’IA. Una documentazione dei campi scadente un tempo puniva il prossimo amministratore. Ora inganna ogni strumento di IA e ogni agente che legge lo schema: Flag2__c è sensibile, autorevole, ancora in uso? L’IA crea anche campi più in fretta di qualsiasi team, quindi nomi, descrizioni e classificazione fanno parte dell’architettura, non delle pulizie di casa.

Ogni campo è un impegno

Una volta che un campo è là fuori a raccogliere dati, tutto comincia ad appoggiarcisi. Le schermate lo mostrano, i flussi ci si ramificano sopra, le regole di convalida lo controllano, i report raggruppano per quel campo, le integrazioni lo inviano e lo leggono, e ora gli strumenti di IA ci ragionano sopra. Ognuno di loro fa delle ipotesi sul campo: il suo tipo, la sua lunghezza, se è mai vuoto, e cosa significano i suoi valori. Se cambi il campo più tardi, devi prima trovare ognuna di quelle ipotesi. Rinominare un valore di un elenco di selezione, accorciare un campo di testo o trasformare un campo Testo in un elenco di selezione sembra una piccola modifica, e può rompere un’integrazione nel sistema di un’altra azienda. Ecco perché un campo è un impegno.

Click to enlarge

Non voglio che tu esca da questo modulo con la paura di creare campi. Salesforce è costruita per essere estesa; usala. Voglio che la domanda cambi da “quale tipo di campo dovrei scegliere?” a “cosa significano questi dati, e a quale comportamento ci stiamo impegnando?”. Tipo, obbligatorio, unico, ID esterno, elenco di selezione, formula, descrizione, classificazione: insieme sono l’espressione fisica del modello logico del capitolo 2.

Cosa decide qui un architetto

• Cosa significa il valore prima di scegliere il tipo di campo, e se è un attributo, un identificatore, un vocabolario controllato o in realtà un’altra entità.
• Se un valore è un calcolo attuale che si può derivare o un fatto storico da memorizzare.
• Quale sistema possiede ogni identificatore, e se la sua unicità è una vera promessa del business.
• Quando un valore obbligatorio è davvero noto, e cosa succede ai record e alle integrazioni che non lo hanno.
• Quale descrizione, quali nomi e quale classificazione servono al campo perché persone, processi e IA possano usarlo in sicurezza.

Per approfondire

• Guida di Salesforce, Data Classification Metadata Fields (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Guida di Salesforce, Einstein Trust Layer: Designed for Trust (opens in a new tab) e Data Masking Limitations in Agentforce (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Guida di Salesforce, Picklist Limitations (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Guida di Salesforce, Formula Field Limits and Restrictions (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (in inglese), consultato il 2026-10-02.