Matching, sammenslåing og overlevelsesregler

🌐 Finnes også på 28 språk

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

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 3 av 6 i kapitlet Masterdata og identitet, kapittel 6 i kurset Data Architect. Hver modul står på egne ben. Forrige: De fire måtene å håndtere masterdata på · Neste: Et kart er ikke en beslutning

Spørsmålet denne modulen besvarer: Hvordan finner du duplikater, og avgjør hvilke verdier som overlever?

Salesforce har to kontakter: Daniel Reyes, Dallas, d.reyes@example.com, og Dan Reyes, Dallas, d.reyes@example.com. Samme person? Sannsynligvis. Skal vi slå dem sammen? Det er et annet spørsmål. Og hvis vi gjør det, hvilket telefonnummer, hvilken adresse og hvilken tittel overlever? Enda et annet. Arkitekter må holde tre beslutninger fra hverandre:

• Matching: representerer disse postene det samme?
• Sammenslåing: skal de bli én post?
• Overlevelsesregler: hvis vi kombinerer data, hvilke verdier vinner?

Matching kommer først

Kapittel 3 dekket duplikatregler og samsvarsregler i Salesforce, så jeg skal ikke lære deg mekanikken på nytt. Det arkitektoniske spørsmålet er hvilke bevis er sterke nok til å si at disse kan være det samme? For en person: e-post, telefon, navn pluss adresse, et kundenummer, en kombinasjon. For et selskap: juridisk navn, organisasjonsnummer, kunde-ID i ERP, adresse, webdomene. Ikke «kan Salesforce sammenligne disse feltene?», men «hvilken kombinasjon gir oss nok trygghet til å handle?»

Og eksakt er ikke sikkert. En delt e-postadresse er et sterkt signal, ikke et bevis: familier deler adresser, bedrifter bruker purchasing@company.com, telefonnumre hører til husholdninger, navn og adresser er ikke unike, og selv sterke identifikatorer blir gjenbrukt, feiltastet eller resirkulert. Matching er ikke tekstsammenligning. Det er et utsagn om identitet.

Hva det koster å ta feil

Når jeg underviser i dette, bytter jeg domene. I markedsføringsdata for bilbransjen avgjør vi feilaktig at to Daniel Reyes er samme person, og feil person får et tilbud på en SUV. Ikke bra, men lav risiko. Gjør nå samme falske match i medisinske data: to forskjellige menneskers sykehistorikk slått sammen. Samme matchingfeil, helt annen konsekvens. Derfor finnes det ingen universell «god» terskel for matching. Noen ganger er den største risikoen å gå glipp av en match; noen ganger er det å kombinere to personer som ikke er de samme. Der falske matcher er kostbare, matcher jeg bevisst for lite.

Harmoniser, så match, så konsolider

Matching avhenger også av formen på dataene. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisering gjør verdier sammenlignbare: standardformater, normaliserte forkortelser, mappede koder. Så matcher du. Først når du vet at postene hører sammen, konsoliderer du informasjonen deres til én representasjon. Å harmonisere er ikke å matche, å matche er ikke å slå sammen, og å konsolidere er ikke nødvendigvis å mastre.

Click to enlarge

Identitetsbeslutninger skjer i trinn.

En match krever ikke en sammenslåing

Dette er et av de viktigste skillene i kapitlet. Vi er sikre på at to kundeposter fra to gamle systemer er samme selskap. Må vi slå dem sammen? Nei. Hver kan bære en identitet fra kildesystemet; historiske transaksjoner kan peke på hver av dem; revisorer kan trenge sporet; vi kan fortsatt være midt i en migrering; vi kan trenge å vite nøyaktig hva det gamle systemet sa. Å vite at to poster er det samme, tvinger oss ikke til å slå dem sammen. Vi kan koble dem, og det er ofte den tryggere arkitekturen.

Min regel for sammenslåing: en klar vinner

Mitt standpunkt: slå sammen bare når det finnes en klar vinner og duplikatet ikke tilfører noe du trenger å beholde. En selger opprettet en duplikatkonto i går; originalen er tydelig den etablerte posten. God kandidat for sammenslåing. Endre det nå: vi importerte kunder fra et gammelt system, med egne ID-er, eldre verdier, kanskje transaksjoner eller revisjonskrav knyttet til dem. Da er jeg mye mer forsiktig. Behold duplikater fra eksterne innlastinger når du kan få bruk for å spore tilbake til eldre verdier, fordi sammenslåing ødelegger den historikken.

Hva en sammenslåing i Salesforce faktisk gjør

En kobling sier «disse hører sammen». En sammenslåing sier «disse er nå én», og i Salesforce er det en reell endring. For kontoer velger du opptil tre poster og velger én som hovedpost (principal); du velger hvilke av de andres feltverdier som skal beholdes, mens skjulte og skrivebeskyttede felt kommer fra hovedposten. Den sammenslåtte posten beholder Created By og Created Date fra den eldste posten, uansett hvilken som er hovedpost. Postene som ikke er hovedpost, havner i papirkurven (Recycle Bin). Relaterte poster som aktiviteter flyttes til den sammenslåtte posten, med unntak. I Lightning fungerer sammenslåing på duplikatene som duplikatreglene dine oppdager. Og for personkontoer støtter ikke contact point-objekter sammenslåing: relasjonene deres går tapt (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Eksamenskunnskap. Vit hva en sammenslåing av kontoer i Salesforce gjør: opptil tre poster; én hovedpost, der skjulte og skrivebeskyttede felt beholdes; Created By og Created Date fra den eldste posten, uansett hvilken som er hovedpost; de andre postene havner i papirkurven; og for personkontoer slås ikke contact point-objekter sammen.

Du trenger ikke hvert eneste grensetilfelle for å ta beslutningen. Du trenger konsekvensen: etter en sammenslåing er de uavhengige postene du startet med, borte. Reversibilitetstesten fra kapittel 1 gjelder: en kobling er lett å angre; en sammenslåing er det ikke. Og en kunde står sjelden alene: kontakter, saker, salgsmuligheter, filer, samtykkeposter, egendefinerte barn, eksterne ID-er, integrasjonsreferanser. Før du slår sammen forelderen, må du forstå hva som skjer med alt som henger på den. Når duplikater kommer inn med en innlasting, gir jeg teamene tre valg for barna: flytt dem til posten som overlever; ikke last dem inn i det hele tatt, hvis ingen trenger dem; eller behold dem på den andre posten, merket som inaktive, så de fortsatt dukker opp i søk. Det første er det en sammenslåing gjør for deg. De to andre beholder sporet, og det er ofte hele poenget.

Overlevelsesregler: hvilken verdi vinner?

Postene hører sammen, men de er uenige: Salesforce og fakturering sier 602-555-0100, ERP-systemet sier 602-555-0188. Overlevelsesregler (survivorship) velger vinneren. De vanlige: nyeste (den siste oppdateringen), hyppigste (verdien flest kilder er enige om) og kildeprioritet (stol på denne kilden framfor den), pluss kombinasjoner, terskler, vekter og forretningsspesifikke regler. Ingen av dem er riktig i seg selv.

«Nyeste» er ikke en teknisk innstilling. Det er et utsagn om tillit: når systemene er uenige, er den nyeste verdien mer sannsynlig riktig. Rimelig for et mobilnummer. Forferdelig for et juridisk navn: hvis ERP-systemet eier det, bryr jeg meg ikke om at noen endret kopien i Salesforce for fem minutter siden. «Hyppigste» antar at enighet er bevis, men tre utdaterte kopier nedstrøms overstyrer ikke kildesystemet. «Kildeprioritet» sier det rett ut: vi stoler mer på denne kilden. Så overlevelsesregler hører hjemme i arkitektur og styring, og hver regel trenger en eier. Hvem bestemte at den nyeste adressen vinner, eller at ERP-systemet rangerer over Salesforce?

Hvis autoritetskartet fra modul 1 allerede sier at ERP-systemet eier kredittgrensen, er overlevelsesreglene enkle: ERP-systemet vinner, ingen smart poengberegning trengs. De vanskelige tilfellene er attributter der autoriteten er delt, uklar eller basert på bevis i stedet for én master. Det er der overlevelsesreglene gjør seg fortjent.

Click to enlarge

Overlevelsesregler er utsagn om tillit.

Terskler, gjennomgang og beriking

Noe matching veier bevisene: en match på kunde-ID er svært sterk, e-post sterk, telefon middels, et lignende navn svakt, en lignende adresse støttende. Over én poengsum er det en match; under en annen er det forskjellige; imellom går en person gjennom den. Algoritmen er ikke lærdommen. Terskelen er toleransen din for feil, og den bør følge forretningsrisikoen. Og når bevisene reiser spørsmålet uten å avgjøre det, ikke late som om systemet vet. Send det til gjennomgang. Tregere, og det er greit: automatisering er ikke verdifull når den selvsikkert slår sammen to forskjellige kunder.

Beriking legger til enda et spørsmål om opphav. Postreferansedata, bransjekoder, firmografiske data, eksterne risikoscorer forbedrer masterdata, men hvor kom hver verdi fra, hvor pålitelig og oppdatert er den, kan vi bruke den til dette formålet, inneholder den personopplysninger? «Bransje = Transport» fra en dataleverandør er ikke det samme som at kunden har fortalt deg det. Hold på det skillet.

Steve Trucking: lik er ikke det samme

To detaljhandelspartnere (Retail Partners) sender leveringer til John Smith, 123 Main Street, Columbus, med samme telefonnummer. Samme person? Sannsynligvis. Bør Steve Trucking samle dem? Husk hvem de tilhører: de mottakerne (Recipients) er partnernes kunder, og én partner må aldri se en annens. En falsk match ville blandet data på tvers av den grensen. Plutselig er det ikke et datakvalitetsspørsmål, men et spørsmål om personvern og isolasjon, og det er nettopp derfor terskler avhenger av konsekvenser. Kontrollpunktet tar avgjørelsen. Foreløpig: ikke la det at matching er praktisk, ta forretningsbeslutningen.

Noen ganger forteller rotet deg noe hvis du beholder det. Denne posten kom fra det gamle systemet, den fra Salesforce, denne fra det oppkjøpte selskapet; ID-ene deres, historikken deres og det faktum at de var uenige, kan alt sammen bety noe. Rene data er verdifulle. Det er sporbarhet også. Arkitekten avgjør hva som betyr mest for bruken.

Utover eksamen: hva KI endrer. En dårlig match pleide å bety to e-poster eller en oppsplittet servicehistorikk. Nå finner en agent det den tror er kunden, og henter ordrene, sakene, adressene og notatene. Hvis to personer ble feilaktig matchet, kan den handle på én persons informasjon for en annen. Matchingbeslutningen har blitt en del av sikkerhetsgrensen, og der sammenblanding er kostbart, er strengere matching det tryggere designet.

Hva en arkitekt bestemmer her

• Hvilke bevis som er nok til å flagge et mulig duplikat i hvert datadomene.
• Om en bekreftet match blir en sammenslåing, en kobling eller en manuell gjennomgang.
• Hvilke verdier som overlever uenighet, og hvem som eier hver overlevelsesregel.
• Hvor mye risiko for falske matcher virksomheten tåler, mot risikoen for tapte matcher.
• Hvilke kildeidentiteter, hvilken historikk og hvilke relaterte poster som må bevares før en sammenslåing.

Match nøye, slå sammen med vilje, velg overlevelsesregler bevisst. En ren kundepost er ikke mye verdt hvis du kom dit ved å kombinere feil kunder.

Les mer

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) og Merge Duplicate Accounts in Lightning Experience (opens in a new tab), på engelsk, kontrollert 2026-10-14.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab), på engelsk, kontrollert 2026-10-14.