Matchning, sammenfletning og overlevelsesregler

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 3 af 6 i kapitlet Masterdata og identitet, kapitel 6 i kurset Data Architect. Hvert modul står på egne ben. Forrige: De fire måder at håndtere masterdata på · Næste: Et kort er ikke en beslutning

Spørgsmålet, dette modul besvarer: Hvordan finder du dubletter, og hvordan beslutter du, hvilke værdier der overlever?

Salesforce har to kontakter: Daniel Reyes, Dallas, d.reyes@example.com, og Dan Reyes, Dallas, d.reyes@example.com. Samme person? Sandsynligvis. Skal vi flette dem sammen? Det er et andet spørgsmål. Og hvis vi gør, hvilket telefonnummer, hvilken adresse og hvilken titel overlever så? Igen et andet spørgsmål. Arkitekter skal holde tre beslutninger adskilt:

• Matchning: Repræsenterer disse poster det samme?
• Sammenfletning: Skal de blive til én post?
• Overlevelsesregler (survivorship): Hvis vi kombinerer data, hvilke værdier vinder så?

Matchning kommer først

Kapitel 3 gennemgik Salesforces dubletregler og matchningsregler, så jeg vil ikke undervise i mekanikken igen. Det arkitektoniske spørgsmål er: Hvilket bevis er stærkt nok til at sige, at disse måske er de samme? For en person: e-mail, telefon, navn plus adresse, et kundenummer, en kombination. For en virksomhed: juridisk navn, skatte-id, ERP’ets kunde-id, adresse, webdomæne. Ikke »kan Salesforce sammenligne disse felter?«, men »hvilken kombination giver os tilstrækkelig sikkerhed til at handle?«

Og præcist er ikke det samme som sikkert. En fælles e-mail er et stærkt signal, ikke et bevis: Familier deler adresser, virksomheder bruger purchasing@company.com, telefonnumre hører til husstande, navne og adresser er ikke unikke, og selv stærke identifikatorer bliver genbrugt, tastet forkert eller genanvendt. Matchning er ikke strengsammenligning. Det er en udtalelse om identitet.

Prisen for at tage fejl

Når jeg underviser i det her, skifter jeg domæne. I markedsføringsdata i bilbranchen beslutter vi fejlagtigt, at to Daniel Reyes er den samme person, og den forkerte får et tilbud på en SUV. Ikke godt, men lav risiko. Lav nu det samme falske match i medicinske data: to forskellige personers sygehistorik slået sammen. Samme matchningsfejl, en helt anden konsekvens. Derfor findes der ikke en universel »god« tærskel for matchning. Nogle gange er den største risiko at overse et match; andre gange er det at slå to personer sammen, der ikke er de samme. Hvor falske match er dyre, undermatcher jeg med vilje.

Harmonisér, så match, så konsolidér

Matchning afhænger også af dataenes form. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisering gør værdier sammenlignelige: standardformater, normaliserede forkortelser, mappede koder. Så matcher du. Først når det er kendt, at posterne hører sammen, konsoliderer du deres oplysninger i én repræsentation. At harmonisere er ikke at matche, at matche er ikke at flette sammen, og at konsolidere er ikke nødvendigvis at mastere.

Click to enlarge

Beslutninger om identitet sker i trin.

Et match kræver ikke en sammenfletning

Det her er en af de vigtigste skelnen i kapitlet. Vi er sikre på, at to kundeposter fra to gamle systemer er den samme virksomhed. Skal vi så flette dem sammen? Nej. Hver kan bære en identitet fra kildesystemet; historiske transaktioner kan pege på hver af dem; revisorer kan have brug for sporet; vi er måske stadig ved at migrere; vi kan have brug for at vide præcis, hvad det gamle system sagde. At vide, at to poster er det samme, tvinger os ikke til at slå dem sammen. Vi kan linke dem, og det er ofte den sikreste arkitektur.

Min regel for sammenfletning: en klar vinder

Min holdning: Flet kun sammen, når der er en klar vinder, og dubletten ikke tilføjer noget, du har brug for at beholde. En sælger oprettede i går en dublet af en konto; originalen er tydeligvis den etablerede post. En god kandidat til sammenfletning. Lad os nu ændre det: Vi importerede kunder fra et ældre system med dets egne id’er, ældre værdier og måske transaktioner eller revisionskrav knyttet til dem. Så er jeg langt mere forsigtig. Behold dubletter fra eksterne indlæsninger, når du måske skal spore tilbage til ældre værdier, for sammenfletning ødelægger den historik.

Hvad en sammenfletning i Salesforce faktisk gør

Et link siger »disse hører sammen«. En sammenfletning siger »disse er nu én«, og i Salesforce er det en reel ændring. For konti vælger du op til tre poster og udpeger én som hovedpost (principal); du vælger, hvilke af de andres feltværdier der skal beholdes, mens skjulte og skrivebeskyttede felter kommer fra hovedposten. Den sammenflettede post beholder Created By og Created Date fra den ældste post, uanset hvilken der er hovedpost. De poster, der ikke er hovedpost, ryger i papirkurven (Recycle Bin). Relaterede poster som aktiviteter flytter til den sammenflettede post, med undtagelser. I Lightning virker sammenfletning på de dubletter, dine dubletregler finder. Og for personkonti understøtter kontaktpunktobjekter ikke sammenfletning: Deres relationer går tabt (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab); på engelsk).

Eksamensviden. Kend, hvad en sammenfletning af konti i Salesforce gør: op til tre poster; én hovedpost, hvis skjulte og skrivebeskyttede felter beholdes; Created By og Created Date fra den ældste post, uanset hvilken der er hovedpost; de andre poster ryger i papirkurven (Recycle Bin); og for personkonti bliver kontaktpunktobjekter ikke flettet sammen.

Du behøver ikke kende alle grænsetilfælde for at træffe beslutningen. Du skal kende konsekvensen: Efter en sammenfletning er de selvstændige poster, du startede med, væk. Reversibilitetstesten fra kapitel 1 gælder: Et link er let at fortryde; en sammenfletning er ikke. Og en kunde står sjældent alene: kontakter, sager, salgsmuligheder, filer, samtykkeposter, brugerdefinerede underordnede poster, eksterne id’er, integrationsreferencer. Før du fletter forælderen sammen, så forstå, hvad der sker med alt, der hænger på den. Når dubletter kommer ind med en indlæsning, giver jeg teamene tre valg for de underordnede poster: Flyt dem til den post, der overlever; lad være med at indlæse dem, hvis ingen har brug for dem; eller behold dem på den anden post, markeret som inaktiv, så de stadig dukker op i søgninger. Det første er det, en sammenfletning gør for dig. De to andre bevarer sporet, og det er ofte hele pointen.

Overlevelsesregler: hvilken værdi vinder?

Posterne hører sammen, men de er uenige: Salesforce og faktureringen siger 602-555-0100, ERP’et siger 602-555-0188. Overlevelsesregler vælger vinderen. De almindelige: nyeste (den seneste opdatering), hyppigste (den værdi, flest kilder er enige om) og kildeprioritet (stol mere på denne kilde end på den), plus kombinationer, tærskler, vægte og forretningsspecifikke regler. Ingen af dem er rigtig i sig selv.

»Nyeste« er ikke en teknisk indstilling. Det er en udtalelse om tillid: Når systemer er uenige, er den nyeste værdi mere sandsynligt korrekt. Rimeligt for et mobilnummer. Forfærdeligt for et juridisk navn: Hvis ERP’et ejer det, er jeg ligeglad med, at nogen ændrede kopien i Salesforce for fem minutter siden. »Hyppigste« antager, at enighed er bevis, men tre forældede kopier længere nede i kæden kan ikke stemme kildesystemet ned. »Kildeprioritet« siger det ligeud: Vi stoler mere på denne kilde. Så overlevelsesregler hører hjemme i arkitektur og styring, og hver regel har brug for en ejer. Hvem besluttede, at den nyeste adresse vinder, eller at ERP’et rangerer over Salesforce?

Hvis autoritetskortet fra modul 1 allerede siger, at ERP’et ejer kreditgrænsen, er overlevelsesreglen let: ERP’et vinder, der er ikke brug for smart pointgivning. De svære tilfælde er attributter, hvor autoriteten er delt, uklar eller bygger på beviser i stedet for på én master. Det er dér, overlevelsesregler gør sig fortjent til deres plads.

Click to enlarge

Overlevelsesregler er udtalelser om tillid.

Tærskler, gennemgang og berigelse

Noget matchning vejer beviserne: Et match på kunde-id er meget stærkt, en e-mail stærk, en telefon moderat, et lignende navn svagt, en lignende adresse understøttende. Over én score er det et match; under en anden er de forskellige; derimellem gennemgår et menneske det. Algoritmen er ikke lektien. Tærsklen er din tolerance for fejl, og den skal følge forretningsrisikoen. Og når beviserne rejser spørgsmålet uden at afgøre det, så lad ikke, som om systemet ved det. Send det til gennemgang. Langsommere, og det er fint: Automatisering er ikke værdifuld, når den selvsikkert fletter to forskellige kunder sammen.

Berigelse tilføjer endnu et spørgsmål om oprindelse. Postale referencedata, branchekoder, virksomhedsdata og eksterne risikoscorer forbedrer masterdata, men hvor kom hver værdi fra, hvor pålidelig og aktuel er den, må vi bruge den til dette formål, rummer den personoplysninger? »Branche = Transport« fra en dataleverandør er ikke det samme, som at kunden fortæller dig det. Hold fast i den skelnen.

Steve Trucking: lignende er ikke det samme

To detailpartnere sender leveringer til John Smith, 123 Main Street, Columbus, med det samme telefonnummer. Samme person? Sandsynligvis. Skal Steve Trucking samle dem? Husk, hvis de er: De modtagere er partnernes kunder, og én partner må aldrig se en andens. Et falsk match ville blande data på tværs af den grænse. Pludselig er det ikke et spørgsmål om datakvalitet, men om databeskyttelse og adskillelse, og det er netop derfor, tærskler afhænger af konsekvenser. Kontrolpunktet træffer beslutningen. Indtil videre: Lad ikke bekvem matchning træffe forretningsbeslutningen.

Nogle gange fortæller rodet dig noget, hvis du beholder det. Denne post kom fra det gamle system, den fra Salesforce, den her fra det opkøbte firma; deres id’er, deres historik og det faktum, at de var uenige, kan alt sammen have betydning. Rene data er værdifulde. Det er sporbarhed også. Arkitekten afgør, hvad der betyder mest for formålet.

Ud over eksamen: hvad AI ændrer. Et dårligt match betød før to e-mails eller en opsplittet servicehistorik. Nu finder en agent det, den tror er kunden, og henter vedkommendes ordrer, sager, adresser og noter. Hvis to personer blev matchet forkert, kan den handle på én persons oplysninger på vegne af en anden. Matchningsbeslutningen er blevet en del af sikkerhedsgrænsen, og hvor det er dyrt at blande sammen, er strengere matchning det sikreste design.

Hvad en arkitekt beslutter her

• Hvilket bevis der er nok til at markere en mulig dublet i hvert datadomæne.
• Om et bekræftet match bliver til en sammenfletning, et link eller en manuel gennemgang.
• Hvilke værdier der overlever uenighed, og hvem der ejer hver overlevelsesregel.
• Hvor stor risiko for falske match forretningen kan tåle i forhold til risikoen for oversete match.
• Hvilke kildeidentiteter, hvilken historik og hvilke relaterede poster der skal bevares før en sammenfletning.

Match omhyggeligt, flet bevidst sammen, vælg overlevelsesregler med vilje. En ren kundepost er ikke meget værd, hvis du nåede dertil ved at slå de forkerte kunder sammen.

Læs mere

• 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, kontrolleret 2026-10-14).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).