Corrispondenza, unione e survivorship

🌐 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 3 di 6 del capitolo Dati master e identità, capitolo 6 del corso Data Architect. Ogni modulo si regge da solo. Precedente: I quattro modi di gestire i dati master · Successivo: Una mappa non è una decisione

La domanda a cui risponde questo modulo: Come trovi i duplicati, e come decidi quali valori sopravvivono?

Salesforce ha due contatti: Daniel Reyes, Dallas, d.reyes@example.com, e Dan Reyes, Dallas, d.reyes@example.com. La stessa persona? Probabilmente. Dovremmo unirli? È un’altra domanda. E se lo facciamo, quale numero di telefono, indirizzo e qualifica sopravvivono? Un’altra ancora. Gli architetti devono tenere separate tre decisioni:

• Corrispondenza (matching): questi record rappresentano la stessa cosa?
• Unione (merge): dovrebbero diventare un solo record?
• Survivorship (quale valore sopravvive): se combiniamo i dati, quali valori vincono?

Prima viene la corrispondenza

Il capitolo 3 ha trattato le regole duplicati e di corrispondenza di Salesforce, quindi non rispiego la meccanica. La domanda architetturale è quali prove sono abbastanza forti da dire che potrebbero essere la stessa cosa? Per una persona: email, telefono, nome più indirizzo, un numero cliente, una qualche combinazione. Per un’azienda: ragione sociale, partita IVA, ID cliente ERP, indirizzo, dominio web. Non “Salesforce può confrontare questi campi?” ma “quale combinazione ci dà abbastanza fiducia per agire?”

E identico non vuol dire certo. Un’email condivisa è un segnale forte, non una prova: le famiglie condividono gli indirizzi, le aziende usano purchasing@company.com, i numeri di telefono appartengono a un nucleo familiare, nomi e indirizzi non sono unici, e anche gli identificatori forti vengono riutilizzati, digitati male o riciclati. La corrispondenza non è un confronto tra stringhe. È un’affermazione sull’identità.

Il costo dell’errore

Quando lo insegno, cambio dominio. Nei dati di marketing del settore automobilistico, decidiamo per sbaglio che due Daniel Reyes sono la stessa persona, e quello sbagliato riceve un’offerta per un SUV. Non bene, ma a basso rischio. Ora fai la stessa falsa corrispondenza nei dati sanitari: le storie cliniche di due persone diverse combinate. Stesso errore di corrispondenza, conseguenza completamente diversa. Ecco perché non esiste una soglia di corrispondenza “buona” universale. A volte il rischio maggiore è perdere una corrispondenza; a volte è combinare due persone che non sono la stessa. Dove le false corrispondenze costano caro, corrispondo di meno di proposito.

Armonizza, poi fai corrispondere, poi consolida

La corrispondenza dipende anche dalla forma dei dati. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. L’armonizzazione rende i valori confrontabili: formati standard, abbreviazioni normalizzate, codici mappati. Poi fai corrispondere. Solo quando si sa che i record vanno insieme ne consolidi le informazioni in un’unica rappresentazione. Armonizzare non è far corrispondere, far corrispondere non è unire, e consolidare non è necessariamente gestire come dato master.

Click to enlarge

Le decisioni sull’identità avvengono per fasi.

Una corrispondenza non richiede un’unione

È una delle distinzioni più importanti del capitolo. Siamo sicuri che due record cliente provenienti da due vecchi sistemi siano la stessa azienda. Dobbiamo unirli? No. Ciascuno può portare l’identità di un sistema di origine; le transazioni storiche possono puntare a ciascuno; i revisori possono aver bisogno della traccia; potremmo essere ancora in migrazione; potremmo aver bisogno di sapere esattamente cosa diceva il vecchio sistema. Sapere che due record sono la stessa cosa non ci costringe a fonderli. Possiamo collegarli, ed è spesso l’architettura più sicura.

La mia regola sull’unione: un vincitore chiaro

La mia posizione: unisci solo quando c’è un vincitore chiaro e il duplicato non aggiunge nulla che ti serva conservare. Un commerciale ha creato ieri un account duplicato; l’originale è chiaramente il record consolidato. Buon candidato per l’unione. Ora cambia lo scenario: abbiamo importato clienti da un sistema legacy, con i suoi ID, valori più vecchi, magari transazioni o requisiti di audit legati a essi. Sono molto più prudente. Tieni i duplicati che vengono da caricamenti esterni quando potresti doverli ricondurre ai valori più vecchi, perché l’unione distrugge quello storico.

Cosa fa davvero un’unione in Salesforce

Un collegamento dice “questi vanno insieme”. Un’unione dice “questi ora sono uno solo”, e su Salesforce è una modifica reale. Per gli account, selezioni fino a tre record e ne scegli uno come principale; scegli quali valori dei campi degli altri conservare, mentre i campi nascosti e di sola lettura vengono dal principale. Il record unito conserva il Creato da e la Data di creazione del record più vecchio, qualunque sia il principale. I record non principali vanno nel Cestino. I record correlati come le attività passano al record unito, con delle eccezioni. In Lightning, l’unione funziona sui duplicati rilevati dalle tue regole duplicati. E per gli account personali, gli oggetti punto di contatto non supportano l’unione: le loro relazioni vanno perse (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Da sapere per l’esame. Sappi cosa fa un’unione di account in Salesforce: fino a tre record; un record principale, di cui vengono mantenuti i campi nascosti e di sola lettura; il Creato da e la Data di creazione del record più vecchio (Created By, Created Date), qualunque sia il principale; gli altri record vanno nel Cestino; e per gli account personali, gli oggetti dei punti di contatto non vengono uniti.

Non ti serve conoscere ogni caso limite per prendere la decisione. Ti serve la conseguenza: dopo un’unione, i record indipendenti da cui sei partito non ci sono più. Vale il Test di Reversibilità del capitolo 1: un collegamento è facile da annullare; un’unione no. E un cliente raramente sta da solo: contatti, casi, opportunità, file, record di consenso, figli personalizzati, ID esterni, riferimenti delle integrazioni. Prima di unire il padre, capisci cosa succede a tutto ciò che vi è attaccato. Quando i duplicati arrivano con un caricamento, do ai team tre scelte per i figli: spostarli sul record che sopravvive; non caricarli affatto, se non servono a nessuno; oppure tenerli sull’altro record, segnato come inattivo, così compaiono ancora nella ricerca. La prima è ciò che un’unione fa per te. Le altre due conservano la traccia, ed è spesso proprio questo il punto.

Survivorship: quale valore vince?

I record vanno insieme, ma non sono d’accordo: Salesforce e la fatturazione dicono 602-555-0100, l’ERP dice 602-555-0188. Le regole di survivorship scelgono il vincitore. Le più comuni: il più recente (l’ultimo aggiornamento), il più frequente (il valore su cui concordano più fonti) e la priorità della fonte (fidati di questa fonte più che di quella), più combinazioni, soglie, pesi e regole specifiche del business. Nessuna è giusta di per sé.

“Il più recente” non è un’impostazione tecnica. È un’affermazione sulla fiducia: quando i sistemi non sono d’accordo, il valore più nuovo ha più probabilità di essere corretto. Ragionevole per un numero di cellulare. Terribile per una ragione sociale: se la possiede l’ERP, non mi importa che qualcuno abbia cambiato la copia in Salesforce cinque minuti fa. “Il più frequente” presuppone che l’accordo sia una prova, ma tre copie vecchie a valle non mettono in minoranza la fonte autorevole. “La priorità della fonte” lo dice chiaramente: ci fidiamo di più di questa fonte. Quindi la survivorship appartiene all’architettura e alla governance, e ogni regola ha bisogno di un responsabile. Chi ha deciso che vince l’indirizzo più nuovo, o che l’ERP conta più di Salesforce?

Se la mappa delle autorità del modulo 1 dice già che l’ERP possiede il limite di credito, la survivorship è facile: vince l’ERP, nessun punteggio ingegnoso necessario. I casi difficili sono gli attributi in cui l’autorità è condivisa, poco chiara o basata su prove invece che su un solo master. È lì che le regole di survivorship si guadagnano il loro posto.

Click to enlarge

Le regole di survivorship sono dichiarazioni di fiducia.

Soglie, revisione e arricchimento

Alcune corrispondenze pesano le prove: una corrispondenza sull’ID cliente è fortissima, un’email forte, un telefono moderata, un nome simile debole, un indirizzo simile di supporto. Sopra un certo punteggio, una corrispondenza; sotto un altro, record diversi; nel mezzo, li rivede una persona. L’algoritmo non è la lezione. La soglia è la tua tolleranza all’errore, e dovrebbe seguire il rischio di business. E quando le prove sollevano la domanda senza risolverla, non fingere che il sistema sappia. Mandala in revisione. Più lento, e va bene: l’automazione non ha valore quando unisce con sicurezza due clienti diversi.

L’arricchimento aggiunge un’altra domanda sulla provenienza. Dati di riferimento postali, codici di settore, dati aziendali, punteggi di rischio esterni migliorano i dati master, ma da dove viene ogni valore, quanto è affidabile e aggiornato, possiamo usarlo per questa finalità, contiene dati personali? “Settore = Trasporti” da un fornitore di dati non è la stessa cosa che sentirlo dal cliente. Mantieni quella distinzione.

Steve Trucking: simile non è uguale

Due Partner retail inviano consegne a John Smith, 123 Main Street, Columbus, con lo stesso numero di telefono. La stessa persona? Probabilmente. Steve Trucking dovrebbe unificarli? Ricorda di chi sono: quei Destinatari sono clienti dei partner, e un partner non deve mai vedere quelli di un altro. Una falsa corrispondenza mescolerebbe dati oltre quel confine. All’improvviso non è più una questione di qualità dei dati ma di privacy e di isolamento, ed è proprio per questo che le soglie dipendono dalle conseguenze. La decisione la prende il checkpoint. Per ora: non lasciare che la comodità della corrispondenza prenda la decisione di business.

A volte tenere il disordine ti dice qualcosa. Questo record viene dal vecchio sistema, quello da Salesforce, quest’altro dall’azienda acquisita; i loro ID, il loro storico e il fatto stesso che non fossero d’accordo possono contare tutti. I dati puliti hanno valore. Anche la tracciabilità. L’architetto decide cosa conta di più per l’uso che se ne fa.

Oltre l’esame: cosa cambia l’IA. Una cattiva corrispondenza un tempo significava due email o uno storico di assistenza diviso in due. Ora un agente trova quello che crede sia il cliente e ne recupera ordini, casi, indirizzi e note. Se due persone sono state fatte corrispondere per sbaglio, può agire sulle informazioni di una persona per conto di un’altra. La decisione sulla corrispondenza è diventata parte del confine di sicurezza, e dove mescolare costa caro, una corrispondenza più severa è il progetto più sicuro.

Cosa decide qui un architetto

• Quali prove bastano per segnalare un possibile duplicato in ogni dominio di dati.
• Se una corrispondenza confermata diventa un’unione, un collegamento o una revisione umana.
• Quali valori sopravvivono al disaccordo, e chi è responsabile di ogni regola di survivorship.
• Quanto rischio di falsa corrispondenza può tollerare il business rispetto al rischio di corrispondenze mancate.
• Quali identità di origine, quale storico e quali record correlati vanno preservati prima di qualsiasi unione.

Fai corrispondere con attenzione, unisci in modo deliberato, scegli le regole di survivorship con intenzione. Un record cliente pulito non vale molto se ci sei arrivato combinando i clienti sbagliati.

Per approfondire

• Guida di Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab) e Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (in inglese), consultato il 2026-10-14.