Mantenere i dati coerenti

🌐 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 9 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Titolarità e ciclo di vita · Successivo: Progetta il modello fisico Salesforce

La domanda a cui risponde questo modulo: Come mantengo i dati coerenti, e quanto costa ogni livello?

Tutti vogliono dati puliti. Non sono mai entrato in una riunione sui requisiti in cui qualcuno abbia detto: “Quello che vorremmo davvero sono dati incoerenti”. Il disaccordo arriva dopo: dove facciamo rispettare le regole? Sulla schermata? Un campo obbligatorio? Un elenco di selezione, una regola di convalida, una regola duplicati, un flow, Apex? Aiutano tutti. Non sono intercambiabili, e ogni livello ha un costo.

La mia regola generale è spingere la regola il più in basso ragionevolmente possibile. Se un valore può essere solo una di cinque cose, non lasciare che le persone scrivano qualsiasi cosa per poi ripulire più tardi con l’automazione. Se due record non devono mai condividere un identificatore, non affidarti a qualcuno che se ne accorga in un report. Se una regola deve valere che il record arrivi da una schermata, da un’API, da un’integrazione, da un caricamento di dati o da un agente, non farla rispettare solo nell’interfaccia. Più la regola sta vicina ai dati, più è difficile aggirarla. La chiamo la scala della coerenza.

Primo gradino: il tipo di campo e il vocabolario

La prima regola di coerenza è quella del modulo 6: scegli il tipo giusto. Una data è una Data, un momento è una Data/ora, il denaro è Valuta. È coerenza prima ancora che qualcuno scriva una regola.

Fai dello stato di una consegna un campo di testo e otterrai Delivered, delivered, DELIVERED, Complete, Done e Dropped off, e qualcuno dovrà capire se quei sei significano la stessa cosa. Oppure definisci il vocabolario una volta sola: Consegnata, un valore, un significato. Rendilo un elenco di selezione con restrizioni, così rifiuta tutto ciò che non è nell’elenco, anche tramite l’API, e usa un set di valori globale quando più campi condividono l’elenco (i dettagli sono nel modulo 6).

Ma non usare un elenco di selezione solo per impedire alle persone di scrivere. È davvero un valore, o un’altra entità? Nove centri di distribuzione con un nome ciascuno possono sembrare un elenco di selezione; nove con indirizzi, responsabili, capacità e camion sono record. La regola dovrebbe rafforzare il modello, non compensarne uno cattivo. E se è davvero un vocabolario controllato, controllalo a livello di campo. Non permettere il caos per poi costruire un flow che trasformi AZ, Arizona, Ariz e Phoenix area nel valore che volevi fin dall’inizio.

Secondo gradino: obbligatorio e unico

Obbligatorio e Unico attraggono perché sono semplici: spunti la casella, problema risolto. A volte. Se ogni camion ha un numero di flotta dal giorno in cui viene creato, e nessun camion lo condivide con un altro, entrambe le caselle esprimono vere regole di business. È coerenza forte.

Ma una volta che la piattaforma fa rispettare una regola, non le importa che il tuo processo abbia un’eccezione il martedì pomeriggio. Uso questo esempio in aula da anni. Un oggetto esiste da un po’, con molti record. Qualcuno aggiunge un campo e spunta Obbligatorio. Prova a creare un record: funziona benissimo. Poi sabato sera, deployment, partono i test, e una vecchia classe di test crea l’oggetto senza il nuovo campo. Bum. Oppure qualcuno modifica un vecchio record di prima che il campo esistesse. Oppure l’integrazione invia lo stesso payload che invia da cinque anni. Bum. “Ma non abbiamo cambiato quel campo.” Alla piattaforma non importa: hai cambiato il contratto di cosa sia un record valido. Una nuova regola non tocca solo i dati nuovi; cambia ciò che puoi fare con quelli vecchi.

Terzo gradino: le regole di convalida

Le regole di convalida ci permettono di dire cose molto più ricche. Se lo stato è Consegnata, l’orario effettivo di consegna deve essere compilato. Se la tappa è un’installazione, la checklist deve essere completa prima che la tappa possa essere chiusa. Girano quando il record viene salvato, quindi proteggono il record che sia stato salvato da una pagina, dall’API, da un caricamento di dati, da un’integrazione o da un agente. È proprio questo il punto. Se la regola deve proteggere il record, mettila dove la incontra ogni scrittura.

E mordono. È la loro forza e il loro costo.

Il problema dei vecchi record

Ecco dove la cosa si fa brutta. Hai un milione di record, e oggi aggiungi una regola: l’orario di consegna non può essere precedente alla partenza del percorso. Sensato. Ma ventimila vecchi record la violano, per colpa di una migrazione di sette anni fa. Un utente apre uno di quei record e cambia il numero di telefono. Salva. La regola scatta. “Ho cambiato un numero di telefono. Perché mi parli di un orario di consegna del 2019?” Domanda legittima.

Quindi una regola di convalida non dovrebbe dire solo cosa deve essere vero. Dovrebbe dire quando farlo rispettare. Funzioni come ISNEW() e ISCHANGED() ti permettono di limitare una regola ai record nuovi, o ai salvataggi in cui i campi rilevanti cambiano davvero (Validation Rule Considerations (opens in a new tab)).

Ma un record non cambia solo quando una persona lo modifica, e molti dei motivi sono fuori dal tuo controllo. L’integrazione aggiorna lo stato durante la notte. Un flow imposta una data. Un responsabile riassegna un territorio e il titolare cambia su diecimila record. Qualcuno modifica un articolo della consegna, il roll-up sulla consegna si ricalcola, e questo salva la consegna, così la regola di convalida della consegna scatta per un utente che non l’ha mai toccata (Roll-Up Summary Field (opens in a new tab) avverte che gli errori di convalida possono comparire sul dettaglio o sul master). Ognuno di quei salvataggi incontra la tua nuova regola. Quindi per ogni nuova regola chiediti: questa regola deve applicarsi a quel salvataggio?

Queste sono le scelte, e le intrecci nella regola:

• Sempre, a ogni salvataggio. Giusto quando la regola riguarda davvero il record e i vecchi dati la superano. Ma sappi cosa significa “ogni salvataggio”: anche un job batch che cambia solo il titolare, o qualsiasi piccola modifica a qualsiasi campo del record, deve superarla.
• Solo per i record nuovi, con ISNEW(). La regola controlla il record una volta, quando viene creato, e mai più. Il passato resta com’era, ma anche il futuro: una modifica successiva può far violare la regola a un record nuovo e nessuno lo fermerà. Se conta, abbinala alla scelta successiva.
• Solo quando cambiano i campi che riguarda, con ISCHANGED(). Modificare il numero di telefono non sveglia la regola sull’orario di consegna.
• Non per certi autori delle scritture. Un’autorizzazione personalizzata, controllata nella formula come $Permission, lascia passare l’utente di integrazione o una migrazione di dati mentre le persone devono comunque rispettare la regola (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Concedila di proposito e a pochi.
• Da una data in avanti, confrontando CreatedDate con il giorno in cui la regola è entrata in vigore, quando “nuovo” significa “da quando abbiamo cominciato a farla rispettare”. A differenza di ISNEW(), continua a controllare quei record a ogni salvataggio successivo, quindi vale lo stesso avvertimento: una modifica minore, come un aggiornamento batch del titolare, può fallire su un record che nel frattempo è cambiato.

Aggiungi una regola a record che hai già? Pensa alle conseguenze prima di attivarla. Ogni record esistente ora deve superarla al prossimo salvataggio, e quel salvataggio può arrivare da dove non te lo aspetti: un’integrazione notturna, un cambio di titolare in batch, un roll-up, un aggiornamento massivo da una visualizzazione elenco. Quali di questi la incontreranno, e cosa succede a quel job quando un record fallisce? La sezione Prima di attivarla ha la sequenza che uso io.

Non riscrivere la storia per far contenta la regola

E i ventimila vecchi record? Se i dati sono sbagliati e conosci i valori giusti, correggili. Ma ho visto un altro tipo di “correzione”: nessuno conosce la verità storica, serve solo che i record passino, così vengono aggiornati con valori che soddisfano la regola di oggi. Non mi piace. Aggiornare i vecchi record per renderli conformi cambia LastModifiedDate e distrugge informazioni storiche chiave, e inventare valori significa fingere di sapere qualcosa sul passato che non sappiamo. Dai alla regola un’esclusione per i record che la precedono invece di riscrivere la storia. Può essere brutto, ma è onesto.

La convalida nell’interfaccia non è convalida dei dati

Rendi obbligatorio un campo in un layout di pagina e gli utenti non possono salvare senza. Poi l’integrazione notturna inserisce 50.000 record. Ha usato la tua pagina? No. Né il caricamento massivo, né il client API, né l’agente. Un requisito nell’interfaccia protegge quella schermata, non i dati. La convalida dei campi nei moduli dinamici si può aggirare allo stesso modo. Quindi chiediti: da dove possono entrare questi dati? Lightning, il portale, il mobile, l’integrazione, l’API, un caricamento massivo, Flow, Apex, un agente. Più porte ci sono, meno mi fido di una regola che ne sorveglia una sola.

Quarto gradino: le regole duplicati

Ora passiamo dalla coerenza dentro un record alla coerenza tra record. Acme Corporation, ACME Corp, Acme Inc.: quattro clienti o uno? Nessuna regola su un campo può rispondere. Le regole di corrispondenza definiscono come vengono confrontati i record; le regole duplicati decidono cosa succede quando si trova un probabile duplicato: consentire con un avviso, bloccare o segnalare. Puoi avere fino a cinque regole duplicati attive per oggetto e fino a tre regole di corrispondenza in ciascuna, e le chiavi di corrispondenza restringono ogni confronto ai 100 duplicati più probabili (Things to Know About Duplicate Rules (opens in a new tab)).

Il loro costo è l’attrito. Se ogni account creato da un commerciale dice Possibile duplicato trovato, a volte è esattamente ciò che vuoi, e a volte le persone imparano a cliccare oltre senza leggere. Record legittimi possono somigliarsi, e un’integrazione può aver bisogno di un comportamento diverso da quello di una persona. E l’avviso è quello di Salesforce: il suo messaggio e il suo elenco di possibili duplicati possono non integrarsi con una schermata personalizzata che hai costruito, e quando il salvataggio è senza interfaccia (headless), un’integrazione, un caricamento di dati, un agente, non c’è proprio nessuna schermata su cui mostrarlo. Quindi decidi come emerge un duplicato su ogni percorso: un avviso per una persona, un salvataggio bloccato e un errore per l’API, oppure l’opzione Report e i set di record duplicati che qualcuno esaminerà più tardi. Una buona architettura non è la massima applicazione delle regole; è l’applicazione giusta.

E verifica quali porte una regola duplicati sorveglia davvero (Things to Know About Duplicate Rules (opens in a new tab)). Tramite l’API e gli strumenti di importazione dei dati nessuno vede l’avviso: una regola impostata per avvisare semplicemente blocca il salvataggio. Alcuni percorsi saltano del tutto le regole: Creazione rapida (Quick Create), il pulsante Ripristina (Undelete), un’unione manuale, i record aggiunti da Lightning Sync o da Einstein Activity Capture. E i record salvati nello stesso momento non vengono confrontati tra loro, solo con i record già presenti in Salesforce. Carica un file con lo stesso cliente due volte, ed entrambe le righe possono passare. Una regola duplicati è una buona rete. Non è una serratura sulla porta.

Da sapere per l’esame. Le regole duplicati non confrontano tra loro i record salvati nello stesso momento, solo con i record già presenti in Salesforce. Tramite l’API e gli strumenti di importazione non c’è alcun avviso: un duplicato intercettato dalla regola semplicemente non viene salvato. E un salvataggio e tutto ciò che mette in moto vengono eseguiti come un’unica transazione: se una parte qualsiasi fallisce, viene annullato tutto.

Un confine. Le regole duplicati tengono pulita una org. Non risolvono l’identità aziendale. Se Salesforce ha Acme Corporation, l’ERP ha ACME-10382 e la fatturazione ha il cliente 77193, una regola duplicati non può dirti che sono la stessa azienda. Sono dati master, capitolo 6.

Quinto gradino: l’automazione

Alcune regole sono troppo complesse per i gradini più bassi: hanno bisogno di record correlati, di un altro sistema, di record dipendenti, di un processo in più passaggi. È il territorio di Flow, Apex, a volte della logica di integrazione. (Non delle Workflow Rules o di Process Builder; non sono più supportati.) L’automazione è potente e più costosa: più parti in movimento, più test, più gestione degli errori, più modi in cui un’automazione può inciampare in un’altra. E il codice porta errori suoi. Se può farlo rispettare il tipo di campo, non scrivo Apex. Se una regola di convalida lo dice con chiarezza, non costruisco un flow perché c’è Flow. Non risolvere un problema di campo con un motore di processi.

Tutto o niente: quando i record cambiano insieme

Finora ogni gradino protegge un salvataggio. Ma i record cambiano insieme: una consegna e i suoi articoli, un ordine e le sue righe, un flow che aggiorna tre oggetti. Qui la piattaforma ti dà una garanzia forte. Un salvataggio e tutto ciò che mette in moto, i trigger, i flow, le classi che richiamano, vengono eseguiti come un’unica transazione: se una parte qualsiasi fallisce, l’intera operazione viene annullata (rollback) e non viene confermato niente (Apex Transactions (opens in a new tab)). Non ti ritrovi con mezza consegna.

Il lavoro massivo è l’eccezione che scegli tu. Un caricamento di dati o un metodo Apex Database può consentire il successo parziale: i record buoni vengono salvati, quelli sbagliati tornano indietro con i loro errori, e qualcuno deve occuparsene (DML Statements vs. Database Class Methods (opens in a new tab)). Spesso è la scelta giusta per un caricamento di un milione di righe, ma allora la coerenza è un processo: chi legge il file degli errori, e cosa succede ai record che hanno fallito?

E poi c’è la tempistica. Due salvataggi nello stesso momento possono superare entrambi un controllo che ciascuno, da solo, non supererebbe. Un flow che cerca un ordine esistente e poi ne crea uno può farne passare due, e abbiamo appena visto che le regole duplicati non confrontano i record salvati nello stesso momento. Un campo segnato come Unico, o un ID esterno, viene controllato dalla piattaforma a ogni salvataggio, quindi solo uno dei due vince. È un motivo in più per spingere l’unicità giù fino al campo. Blocchi, contesa e nuovi tentativi sono un argomento a sé; il capitolo 11, Transazioni, concorrenza e affidabilità, lo approfondisce.

Spingi la regola in basso, finché non sta più lì

“Il più in basso ragionevolmente possibile” non significa “sempre al livello più basso”. Se un campo è obbligatorio solo quando un’opportunità raggiunge una certa fase, renderlo obbligatorio nello schema è sbagliato; la regola è condizionale, quindi una regola di convalida è il gradino giusto. Se un duplicato deve avvisare una persona ma un’integrazione approvata ha la sua riconciliazione, progetta per entrambi i percorsi. L’obiettivo: il livello più basso che rappresenta correttamente la regola di business.

Ogni livello ha un costo

Click to enlarge

È il trade-off che voglio che tu veda. Tipi di campo e valori controllati sono semplici e forti, ma solo per ciò che un campo sa esprimere. Obbligatorio e Unico sono strumenti grezzi: una volta attivi, ogni scrittura deve soddisfarli. Le regole di convalida esprimono condizioni più ricche ma possono bloccare le modifiche ai vecchi record e sorprendere un deployment. Le regole duplicati proteggono tra record ma aggiungono attrito per utenti e integrazioni. L’automazione gestisce qualsiasi cosa ma ti fa carico di orchestrazione, errori, test e prestazioni. Non esiste un livello gratis. Scegli il livello di ogni regola sapendo come fallisce.

Prima di attivarla

Aggiungere una regola a una org esistente è un rollout, non una casella da spuntare. Quanti record la violano oggi, e perché? Sono davvero sbagliati? Possiamo conoscere il valore giusto? La regola è vera storicamente, o solo da ora in poi? Quali integrazioni, test e automazioni la incontreranno? Una buona sequenza: misura, ripulisci ciò che puoi dimostrare essere sbagliato, delimita la regola, aggiungi un’esclusione deliberata per lo storico legittimo, testa ogni percorso di scrittura, poi applicala. Misurare e ripulire sono discipline a sé, profilazione, standardizzazione, monitoraggio, stewardship, e le tratta il capitolo 5, Qualità e governance dei dati. Molto meglio che spuntare una casella il venerdì e scoprire le conseguenze il sabato sera.

Oltre l’esame: cosa cambia l’IA. Un agente può creare record più in fretta di qualsiasi persona, e record sbagliati altrettanto in fretta. “Gli utenti sanno che non si fa” non è una protezione quando l’utente è un agente. Metti le regole importanti nel livello dei dati, dove le incontra chiunque scriva, così l’agente non deve ricordarsi le regole non scritte dell’azienda.

Steve Trucking: proteggi la consegna

Prendi una consegna. Il suo stato viene da un unico vocabolario: un elenco di selezione, con restrizioni. Il riferimento dell’ordine del Partner retail deve essere unico per partner, quindi è un ID esterno, segnato come unico, usato per l’upsert del manifesto di carico. L’orario effettivo di consegna è obbligatorio quando lo stato è Consegnata: una regola di convalida, limitata a quel cambiamento. Una tappa con installazione non può essere chiusa finché la checklist non è completa e le foto richieste non sono state scattate (per una lavastoviglie, il tubo dell’acqua, lo scarico e la messa in bolla): una regola di convalida, o un’automazione se deve controllare le foto memorizzate fuori dalla piattaforma. Lo stesso ordine che arriva due volte da un manifesto reinviato viene intercettato dall’ID esterno; due ordini diversi che si somigliano sono una questione di corrispondenza.

Nota che non ho detto “mettile tutte in un flow”. Ogni regola sta sul suo gradino. Per ogni regola, chiediti: qual è il livello più basso che la fa rispettare correttamente per ogni percorso di scrittura che conta?

Cosa decide qui un architetto

• Su quale gradino sta ogni regola: tipo di campo, vocabolario controllato, obbligatorio o unico, regola di convalida, regola duplicati o automazione.
• Quali percorsi di scrittura vanno protetti: interfaccia, portale, mobile, integrazioni, caricamenti massivi, API, automazione e agenti.
• Se una nuova regola si applica ai record storici, o è limitata ai dati nuovi e modificati con un’esclusione per il passato.
• Se i dati sbagliati esistenti possono essere corretti sulla base di prove, invece di essere riscritti per passare.
• Quanto attrito, complessità e manutenzione vale una regola.

I dati puliti non nascono dal chiedere alle persone di inserire dati buoni. Nascono da un’architettura che rende facile la cosa giusta, difficile quella sbagliata, e difficili da aggirare le regole importanti. Ora mettiamo insieme il capitolo su una porzione di Steve Trucking.

Per approfondire

• Guida di Salesforce, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) e Roll-Up Summary Field (opens in a new tab) (in inglese), consultato il 2026-10-13.
• Guida di Salesforce, Picklist Limitations (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Guida di Salesforce, Validation Rule Considerations (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Guida di Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (in inglese), consultato il 2026-10-13: i limiti, i percorsi in cui le regole non vengono eseguite, i salvataggi da API e importazione bloccati senza avviso, i salvataggi simultanei non confrontati.
• Apex Developer Guide, Apex Transactions (opens in a new tab) e DML Statements vs. Database Class Methods (opens in a new tab) (in inglese), consultato il 2026-10-13: una transazione viene annullata come un’unica unità; i metodi Database possono consentire il successo parziale.
• Guida di Salesforce, Workflow Rules & Process Builder End of Support (opens in a new tab) (in inglese), consultato il 2026-10-02.