Matchning, sammanslagning och överlevnadsregler

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 3 av 6 i kapitlet Masterdata och identitet, kapitel 6 i kursen Data Architect. Varje modul står på egna ben. Föregående: De fyra sätten att hantera masterdata · Nästa: En karta är inget beslut

Frågan den här modulen besvarar: Hur hittar du dubbletter, och hur avgör du vilka värden som överlever?

Salesforce har två kontakter: Daniel Reyes, Dallas, d.reyes@example.com, och Dan Reyes, Dallas, d.reyes@example.com. Samma person? Förmodligen. Ska vi slå samman dem? Det är en annan fråga. Och om vi gör det, vilket telefonnummer, vilken adress och vilken titel överlever? Ännu en annan fråga. Arkitekter behöver hålla isär tre beslut:

• Matchning: representerar de här posterna samma sak?
• Sammanslagning: ska de bli en post?
• Överlevnadsregler (survivorship): om vi kombinerar data, vilka värden vinner?

Matchningen kommer först

Kapitel 3 gick igenom dubblettregler och matchningsregler i Salesforce, så jag tänker inte lära ut mekaniken igen. Den arkitektoniska frågan är vilka bevis som är starka nog för att säga att de här kanske är samma? För en person: e-post, telefon, namn plus adress, ett kundnummer, någon kombination. För ett företag: juridiskt namn, organisationsnummer, kund-ID i ERP:t, adress, webbdomän. Inte ”kan Salesforce jämföra de här fälten?” utan ”vilken kombination ger oss tillräcklig säkerhet för att agera?”

Och exakt är inte säkert. En gemensam e-postadress är en stark signal, inget bevis: familjer delar adresser, företag använder purchasing@company.com, telefonnummer hör till hushåll, namn och adresser är inte unika, och även starka identifierare återanvänds, skrivs fel eller återvinns. Matchning är ingen strängjämförelse. Det är ett uttalande om identitet.

Vad det kostar att ha fel

När jag undervisar om det här byter jag domän. I marknadsföringsdata för bilbranschen avgör vi felaktigt att två Daniel Reyes är samma person, och fel person får ett erbjudande om en SUV. Inte bra, men låg risk. Gör nu samma felaktiga matchning i medicinska data: två olika personers sjukdomshistorik kombineras. Samma matchningsfel, helt olika konsekvens. Därför finns det ingen universellt ”bra” matchningströskel. Ibland är den större risken att missa en matchning; ibland är det att kombinera två personer som inte är samma. Där felaktiga matchningar är dyra matchar jag medvetet för lite.

Harmonisera, matcha sedan, konsolidera sedan

Matchningen beror också på datas form. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisering gör värden jämförbara: standardformat, normaliserade förkortningar, mappade koder. Sedan matchar du. Först när det är känt att posterna hör ihop konsoliderar du deras information till en representation. Att harmonisera är inte att matcha, att matcha är inte att slå samman, och att konsolidera är inte nödvändigtvis att hantera masterdata.

Click to enlarge

Identitetsbeslut fattas i steg.

En matchning kräver ingen sammanslagning

Det här är en av de viktigaste distinktionerna i kapitlet. Vi är säkra på att två kundposter från två gamla system är samma företag. Måste vi slå samman dem? Nej. Var och en kan bära ett ID från sitt källsystem; historiska transaktioner kan peka på var och en; revisorer kan behöva spåret; vi kanske fortfarande migrerar; vi kanske behöver veta exakt vad det gamla systemet sa. Att veta att två poster är samma sak tvingar oss inte att slå ihop dem. Vi kan länka dem, och det är ofta den säkrare arkitekturen.

Min regel för sammanslagning: en tydlig vinnare

Min hållning: slå bara samman när det finns en tydlig vinnare och dubbletten inte tillför något du behöver behålla. En säljare skapade ett dubblettkonto i går; originalet är tydligt den etablerade posten. Bra kandidat för sammanslagning. Ändra nu fallet: vi importerade kunder från ett äldre system, med egna ID:n, äldre värden, kanske transaktioner eller revisionskrav knutna till dem. Då är jag mycket mer försiktig. Behåll dubbletter från externa laddningar när du kan behöva spåra bakåt till äldre värden, eftersom en sammanslagning förstör den historiken.

Vad en sammanslagning i Salesforce faktiskt gör

En länk säger ”de här hör ihop”. En sammanslagning säger ”de här är nu en”, och i Salesforce är det en verklig ändring. För konton väljer du upp till tre poster och väljer en av dem som huvudpost (principal); du väljer vilka fältvärden från de andra som ska behållas, medan dolda och skrivskyddade fält kommer från huvudposten. Den sammanslagna posten behåller Created By och Created Date från den äldsta posten, oavsett vilken som är huvudpost. Posterna som inte är huvudpost hamnar i papperskorgen (Recycle Bin). Relaterade poster som aktiviteter flyttas till den sammanslagna posten, med undantag. I Lightning fungerar sammanslagning på de dubbletter som dina dubblettregler hittar. Och för personkonton stöder kontaktpunktsobjekten (contact point objects) inte sammanslagning: deras relationer går förlorade (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Provkunskap. Känn till vad en sammanslagning av konton i Salesforce gör: upp till tre poster; en huvudpost (principal), vars dolda och skrivskyddade fält behålls; Created By och Created Date från den äldsta posten, oavsett vilken som är huvudpost; de andra posterna hamnar i papperskorgen (Recycle Bin); och för personkonton slås kontaktpunktsobjekten (contact point objects) inte samman.

Du behöver inte kunna varje specialfall för att fatta beslutet. Du behöver konsekvensen: efter en sammanslagning är de oberoende poster du började med borta. Reversibilitetstestet från kapitel 1 gäller: att länka är lätt att ångra; att slå samman är det inte. Och en kund står sällan ensam: kontakter, ärenden, affärsmöjligheter, filer, samtyckesposter, anpassade barnposter, External ID:n, integrationsreferenser. Innan du slår samman föräldern, förstå vad som händer med allt som hänger på den. När dubbletter kommer in med en laddning ger jag teamen tre val för barnposterna: flytta dem till den överlevande posten; ladda inte in dem alls, om ingen behöver dem; eller behåll dem på den andra posten, markerad som inaktiv, så att de fortfarande dyker upp i sökningar. Det första är vad en sammanslagning gör åt dig. De andra två behåller spåret, och det är ofta själva poängen.

Överlevnadsregler: vilket värde vinner?

Posterna hör ihop, men de är oense: Salesforce och faktureringen säger 602-555-0100, ERP:t säger 602-555-0188. Överlevnadsregler väljer vinnaren. De vanliga: senaste (den senaste uppdateringen), vanligaste (värdet som flest källor är överens om) och källprioritet (lita på den här källan framför den där), plus kombinationer, trösklar, vikter och verksamhetsspecifika regler. Ingen av dem är rätt i sig.

”Senaste” är ingen teknisk inställning. Det är ett uttalande om förtroende: när system är oense är det nyaste värdet troligare rätt. Rimligt för ett mobilnummer. Förfärligt för ett juridiskt namn: om ERP:t äger det bryr jag mig inte om att någon ändrade kopian i Salesforce för fem minuter sedan. ”Vanligaste” förutsätter att samstämmighet är bevis, men tre inaktuella kopior längre ned i kedjan röstar inte ut källsystemet. ”Källprioritet” säger det rakt ut: vi litar mer på den här källan. Så överlevnadsregler hör hemma i arkitektur och styrning, och varje regel behöver en ägare. Vem bestämde att den nyaste adressen vinner, eller att ERP:t går före Salesforce?

Om auktoritetskartan från modul 1 redan säger att ERP:t äger kreditgränsen är överlevnadsregeln enkel: ERP:t vinner, ingen smart poängsättning behövs. De svåra fallen är attribut där auktoriteten är delad, oklar eller baserad på bevis snarare än en enda master. Det är där överlevnadsreglerna gör sig förtjänta av sin plats.

Click to enlarge

Överlevnadsregler är uttalanden om förtroende.

Trösklar, granskning och berikning

En del matchning väger bevisen: en träff på kund-ID är mycket stark, e-post stark, telefon måttlig, ett liknande namn svag, en liknande adress stödjande. Över en poäng är det en matchning; under en annan är de olika; däremellan granskar en människa. Algoritmen är inte lärdomen. Tröskeln är din tolerans för fel, och den bör följa affärsrisken. Och när bevisen väcker frågan utan att avgöra den, låtsas inte att systemet vet. Skicka den till granskning. Långsammare, och det är okej: automatisering är inte värdefull när den med säkerhet slår samman två olika kunder.

Berikning lägger till ännu en fråga om ursprung. Postala referensdata, branschkoder, företagsdata och externa riskpoäng förbättrar masterdata, men var kom varje värde ifrån, hur pålitligt och aktuellt är det, får vi använda det för det här syftet, innehåller det personuppgifter? ”Bransch = Transport” från en dataleverantör är inte samma sak som att kunden berättar det för dig. Behåll den skillnaden.

Steve Trucking: likt är inte samma

Två detaljhandelspartner (Retail Partners) skickar leveranser till John Smith, 123 Main Street, Columbus, med samma telefonnummer. Samma person? Förmodligen. Ska Steve Trucking förena dem? Kom ihåg vems de är: de här mottagarna (Recipients) är partnernas kunder, och en partner får aldrig se en annans. En felaktig matchning skulle blanda data över den gränsen. Plötsligt är det ingen fråga om datakvalitet utan om integritet och isolering, vilket är exakt varför trösklar beror på konsekvenser. Kontrollpunkten fattar beslutet. Tills vidare: låt inte bekvämligheten i matchningen fatta affärsbeslutet.

Ibland säger röran dig något om du behåller den. Den här posten kom från det gamla systemet, den där från Salesforce, den här från det uppköpta företaget; deras ID:n, deras historik och det faktum att de var oense kan alla spela roll. Rena data är värdefulla. Det är spårbarhet också. Arkitekten avgör vad som väger tyngst för användningen.

Bortom provet: vad AI ändrar. En dålig matchning brukade betyda två e-postmeddelanden eller en uppdelad servicehistorik. Nu hittar en agent det den tror är kunden och hämtar personens order, ärenden, adresser och anteckningar. Om två personer har matchats felaktigt kan den agera på en persons information för en annan. Matchningsbeslutet har blivit en del av säkerhetsgränsen, och där sammanblandning är dyr är striktare matchning den säkrare designen.

Vad en arkitekt bestämmer här

• Vilka bevis som räcker för att flagga en möjlig dubblett i varje datadomän.
• Om en bekräftad matchning blir en sammanslagning, en länk eller en mänsklig granskning.
• Vilka värden som överlever när källorna är oense, och vem som äger varje överlevnadsregel.
• Hur stor risk för felaktiga matchningar verksamheten kan tolerera, jämfört med risken för missade matchningar.
• Vilka käll-ID:n, vilken historik och vilka relaterade poster som måste bevaras före en sammanslagning.

Matcha noggrant, slå samman medvetet, välj överlevnadsregler avsiktligt. En ren kundpost är inte värd mycket om du kom dit genom att kombinera fel kunder.

Utforska vidare

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