Matchen, samenvoegen en survivorship

🌐 Ook beschikbaar in 28 talen

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

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 3 van 6 in het hoofdstuk Stamgegevens en identiteit, hoofdstuk 6 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: De vier manieren om stamgegevens te beheren · Volgende: Een kaart is geen beslissing

De vraag die deze module beantwoordt: Hoe vind je duplicaten, en beslis je welke waarden overblijven?

Salesforce heeft twee contactpersonen: Daniel Reyes, Dallas, d.reyes@example.com, en Dan Reyes, Dallas, d.reyes@example.com. Dezelfde persoon? Waarschijnlijk. Moeten we ze samenvoegen? Dat is een andere vraag. En als we dat doen, welk telefoonnummer, adres en welke functietitel blijven over? Weer een andere. Architecten moeten drie beslissingen uit elkaar houden:

• Matchen: vertegenwoordigen deze records hetzelfde?
• Samenvoegen: moeten ze één record worden?
• Survivorship: als we data combineren, welke waarden winnen?

Matchen komt eerst

Hoofdstuk 3 behandelde de duplicaat- en overeenkomstregels van Salesforce, dus de mechaniek leg ik niet opnieuw uit. De architectuurvraag is welk bewijs is sterk genoeg om te zeggen dat deze misschien hetzelfde zijn? Voor een persoon: e-mail, telefoon, naam plus adres, een klantnummer, een combinatie. Voor een bedrijf: juridische naam, fiscaal nummer, klant-ID van het ERP, adres, webdomein. Niet “kan Salesforce deze velden vergelijken?” maar “welke combinatie geeft ons genoeg vertrouwen om te handelen?”

En exact is niet zeker. Een gedeeld e-mailadres is een sterk signaal, geen bewijs: gezinnen delen adressen, bedrijven gebruiken purchasing@company.com, telefoonnummers horen bij huishoudens, namen en adressen zijn niet uniek, en zelfs sterke identificatoren worden hergebruikt, verkeerd getypt of gerecycled. Matchen is geen tekenreeksen vergelijken. Het is een uitspraak over identiteit.

De prijs van ongelijk hebben

Als ik dit doceer, verander ik het domein. In marketingdata voor auto’s besluiten we ten onrechte dat twee Daniel Reyesen dezelfde persoon zijn, en de verkeerde krijgt een aanbieding voor een SUV. Niet goed, maar laag risico. Maak nu dezelfde valse match in medische data: de medische geschiedenis van twee verschillende mensen gecombineerd. Dezelfde matchfout, een totaal ander gevolg. Daarom is er geen universele “goede” drempel voor matchen. Soms is het grotere risico een match missen; soms twee mensen combineren die niet dezelfde zijn. Waar valse matches duur zijn, match ik bewust te weinig.

Harmoniseer, match dan, consolideer dan

Matchen hangt ook af van de vorm van de data. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisatie maakt waarden vergelijkbaar: standaardformaten, genormaliseerde afkortingen, gemapte codes. Dan match je. Pas nadat bekend is dat records bij elkaar horen, consolideer je hun informatie tot één weergave. Harmoniseren is geen matchen, matchen is geen samenvoegen, en consolideren is niet per se beheren.

Click to enlarge

Identiteitsbeslissingen gebeuren in fasen.

Een match vraagt geen samenvoeging

Dit is een van de belangrijkste onderscheiden in het hoofdstuk. We zijn ervan overtuigd dat twee klantrecords uit twee oude systemen hetzelfde bedrijf zijn. Moeten we ze samenvoegen? Nee. Elk kan een identiteit uit een bronsysteem dragen; historische transacties kunnen naar elk ervan wijzen; auditors hebben misschien het spoor nodig; we zijn misschien nog aan het migreren; we moeten misschien precies weten wat het oude systeem zei. Weten dat twee records hetzelfde zijn, dwingt ons niet om ze in te klappen. We kunnen ze koppelen, en dat is vaak de veiligere architectuur.

Mijn regel voor samenvoegen: een duidelijke winnaar

Mijn standpunt: voeg alleen samen als er een duidelijke winnaar is en het duplicaat niets toevoegt wat je moet bewaren. Een verkoper maakte gisteren een dubbel account aan; het origineel is duidelijk het gevestigde record. Een goede kandidaat om samen te voegen. Verander het nu: we importeerden klanten uit een verouderd systeem, met eigen ID’s, oudere waarden, misschien transacties of auditeisen die eraan vastzitten. Dan ben ik veel voorzichtiger. Houd duplicaten uit externe loads als je misschien moet terugzoeken naar oudere waarden, want samenvoegen vernietigt die historie.

Wat samenvoegen in Salesforce echt doet

Een koppeling zegt “deze horen bij elkaar”. Samenvoegen zegt “deze zijn nu één”, en in Salesforce is dat een echte wijziging. Voor accounts selecteer je tot drie records en kies je er één als het hoofdrecord (principal); je kiest welke veldwaarden van de andere je houdt, terwijl verborgen en alleen-lezen velden van het hoofdrecord komen. Het samengevoegde record houdt de Created By en Created Date van het oudste record, welk record ook het hoofdrecord is. De andere records gaan naar de prullenbak. Gerelateerde records zoals activiteiten verhuizen naar het samengevoegde record, met uitzonderingen. In Lightning werkt samenvoegen op de duplicaten die je duplicaatregels vinden. En voor persoonsaccounts ondersteunen contactpuntobjecten geen samenvoeging: hun relaties gaan verloren (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Examenkennis. Weet wat een samenvoeging van accounts in Salesforce doet: tot drie records; één hoofdrecord (principal), waarvan de verborgen en alleen-lezenvelden behouden blijven; de Created By en Created Date van het oudste record, welk record ook het hoofdrecord is; de andere records gaan naar de Prullenbak (Recycle Bin); en bij persoonsaccounts worden contactpuntobjecten niet samengevoegd.

Je hebt niet elk randgeval nodig om de beslissing te nemen. Je hebt het gevolg nodig: na een samenvoeging zijn de onafhankelijke records waarmee je begon weg. De omkeerbaarheidstest uit hoofdstuk 1 geldt: koppelen is makkelijk terug te draaien; samenvoegen niet. En een klant staat zelden alleen: contactpersonen, cases, verkoopkansen, bestanden, toestemmingsrecords, aangepaste onderliggende records, externe ID’s, integratieverwijzingen. Voordat je de parent samenvoegt, moet je begrijpen wat er gebeurt met alles wat eraan vastzit. Als duplicaten met een load binnenkomen, geef ik teams drie keuzes voor de onderliggende records: verplaats ze naar het overlevende record; laad ze helemaal niet, als niemand ze nodig heeft; of houd ze op het andere record, gemarkeerd als inactief, zodat ze nog steeds in zoekresultaten opduiken. Het eerste is wat een samenvoeging voor je doet. De andere twee bewaren het spoor, en daar gaat het vaak om.

Survivorship: welke waarde wint?

Records horen bij elkaar, maar ze zijn het oneens: Salesforce en facturatie zeggen 602-555-0100, het ERP zegt 602-555-0188. Survivorshipregels kiezen de winnaar. De gewone: meest recent (de laatste update), meest voorkomend (de waarde waarover de meeste bronnen het eens zijn), en bronprioriteit (vertrouw deze bron boven die), plus combinaties, drempels, gewichten en bedrijfsspecifieke regels. Geen ervan is vanzelf juist.

“Meest recent” is geen technische instelling. Het is een uitspraak over vertrouwen: als systemen het oneens zijn, is de nieuwste waarde waarschijnlijker juist. Redelijk voor een mobiel nummer. Vreselijk voor een juridische naam: als het ERP er eigenaar van is, maakt het me niet uit dat iemand de Salesforce-kopie vijf minuten geleden wijzigde. “Meest voorkomend” neemt aan dat overeenstemming bewijs is, maar drie verouderde kopieën verderop stemmen het bronsysteem niet weg. “Bronprioriteit” zegt het rechtuit: we vertrouwen deze bron meer. Dus survivorship hoort bij architectuur en governance, en elke regel heeft een eigenaar nodig. Wie besliste dat het nieuwste adres wint, of dat het ERP boven Salesforce gaat?

Als de zeggenschapskaart uit module 1 al zegt dat het ERP eigenaar is van de kredietlimiet, is survivorship makkelijk: het ERP wint, geen slimme scoring nodig. De moeilijke gevallen zijn attributen waarvan de zeggenschap gedeeld is, onduidelijk, of gebaseerd op bewijs in plaats van één master. Daar bewijzen survivorshipregels hun waarde.

Click to enlarge

Survivorshipregels zijn uitspraken over vertrouwen.

Drempels, beoordeling en verrijking

Sommige matching weegt het bewijs: een match op klant-ID is heel sterk, een e-mail sterk, een telefoon gemiddeld, een vergelijkbare naam zwak, een vergelijkbaar adres ondersteunend. Boven één score een match; onder een andere verschillend; daartussen beoordeelt een mens het. Het algoritme is niet de les. De drempel is je tolerantie voor fouten, en die hoort het bedrijfsrisico te volgen. En als het bewijs de vraag oproept zonder haar te beslechten, doe dan niet alsof het systeem het weet. Stuur het door voor beoordeling. Langzamer, en dat is prima: automatisering is niets waard als ze vol zelfvertrouwen twee verschillende klanten samenvoegt.

Verrijking voegt nog een herkomstvraag toe. Postale referentiedata, branchecodes, bedrijfsgegevens, externe risicoscores verbeteren stamgegevens, maar waar kwam elke waarde vandaan, hoe betrouwbaar en actueel is ze, mogen we haar voor dit doel gebruiken, bevat ze persoonsgegevens? “Branche = Transport” van een dataleverancier is niet hetzelfde als de klant die het je vertelt. Houd dat onderscheid.

Steve Trucking: vergelijkbaar is niet hetzelfde

Twee retailpartners sturen leveringen naar John Smith, 123 Main Street, Columbus, met hetzelfde telefoonnummer. Dezelfde persoon? Waarschijnlijk. Moet Steve Trucking ze unificeren? Denk eraan van wie ze zijn: die ontvangers zijn de klanten van de partners, en de ene partner mag nooit de klanten van de andere zien. Een valse match zou data over die grens heen vermengen. Opeens is het geen datakwaliteitsvraag meer maar een vraag over privacy en isolatie, en daarom hangen drempels af van gevolgen. De checkpoint neemt de beslissing. Voor nu: laat het gemak van matchen niet de bedrijfsbeslissing nemen.

Soms vertelt het bewaren van de rommel je iets. Dit record kwam uit het oude systeem, dat uit Salesforce, dit van het overgenomen bedrijf; hun ID’s, hun historie en het feit dat ze het oneens waren kunnen er allemaal toe doen. Schone data is waardevol. Herleidbaarheid ook. De architect beslist wat voor het gebruik zwaarder weegt.

Voorbij het examen: wat AI verandert. Een slechte match betekende vroeger twee e-mails of een gesplitste servicehistorie. Nu vindt een agent wat hij voor de klant houdt en haalt diens orders, cases, adressen en notities op. Als twee mensen ten onrechte gematcht zijn, kan hij handelen op de informatie van de ene persoon voor de andere. De matchbeslissing is deel geworden van de beveiligingsgrens, en waar vermengen duur is, is strenger matchen het veiligere ontwerp.

Wat een architect hier beslist

• Welk bewijs genoeg is om in elk datadomein een mogelijk duplicaat te markeren.
• Of een bevestigde match een samenvoeging, een koppeling of een beoordeling door een mens wordt.
• Welke waarden een meningsverschil overleven, en wie eigenaar is van elke survivorshipregel.
• Hoeveel risico op valse matches het bedrijf kan verdragen tegenover het risico op gemiste matches.
• Welke bronidentiteiten, historie en gerelateerde records bewaard moeten blijven vóór elke samenvoeging.

Match zorgvuldig, voeg bewust samen, kies survivorshipregels met opzet. Een schoon klantrecord is niet veel waard als je er kwam door de verkeerde klanten te combineren.

Verder lezen

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) en Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).