Et kort er ikke en beslutning
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)

Modul 4 af 6 i kapitlet Masterdata og identitet, kapitel 6 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Matchning, sammenfletning og overlevelsesregler · Næste: Når autoriteten er delt
Spørgsmålet, dette modul besvarer: Er en samlet profil det samme som en golden record?
Den samme kunde findes i tre systemer. Salesforce kender Daniel Reyes, d.reyes@example.com, Dallas. E-handelssystemet kender Dan Reyes, samme e-mail, Dallas, TX. Support kender Daniel Reyes, 214-555-0100, Dallas. Data 360 beslutter, at alle tre er den samme person, og bygger en samlet profil. Fremragende. Har vi så en golden record? Ikke nødvendigvis. Vi ved, at posterne hører sammen; vi har ikke besluttet, hvilken kilde der ejer sandheden. Det kan forvirre folk: Identitetsopløsning skaber et samlet individ, men ikke en golden record. Så jeg underviser direkte i forskellen:
En samlet profil er et kort. En golden record er en beslutning.
Identitetsopløsning svarer på »hvem?«
Sektion kaldt “Identitetsopløsning svarer på »hvem?« ”Uden identitetsopløsning optræder én person som profiler uden forbindelse: Marketing ser én, salg en anden, service en tredje. Data 360 indlæser dem og bruger regler for identitetsopløsning til at afgøre, hvilke der hører sammen. Så kan vi sige: Disse poster ser ud til at være den samme person. Det løser identitet. Det løser ikke mastering.
Og den samlede profil beholder kortet tilbage til sine kilder. Med Salesforces egne ord er en samlet profil ikke en golden record: Den er et sæt nøgler, hvor identitetslinkobjekter binder hver kildeposts id til den samlede profils id (Data 360 Architecture (opens in a new tab), på engelsk). Den samlede person 10042 mapper til Salesforce-kontakten 003…, e-handelskunden EC-48372 og supportkunden SUP-9128. Originalerne forsvinder ikke. Det ligger meget tæt på registeret fra modul 2.
En samlet profil er et kort tilbage til kildeidentiteterne.
Matchningsregler: strenghed er en risikobeslutning
Sektion kaldt “Matchningsregler: strenghed er en risikobeslutning ”Hvordan afgør Data 360, hvem der bliver samlet? Matchningsregler. Profiler matcher, når alle kriterierne i en regel er opfyldt, og hvis du har flere regler, skaber et match på en hvilken som helst af dem den samlede profil. Salesforces egen vejledning: Brug flere kriterier for præcision (flere adskilte profiler), færre for konsolidering (Identity Resolution Match Rules (opens in a new tab), på engelsk). Så flere kriterier i en regel gør den strengere; flere alternative regler giver flere måder, profiler kan matche på. At konfigurere identitetsopløsning er ikke at »slå matchning til«. Det er at definere, hvilket bevis der er nok til at sige, at disse profiler er én person.
Mere matchning er ikke automatisk bedre. Ti millioner kildeprofiler bliver til otte millioner samlede. Løsn reglerne, og nu er det seks millioner. Bedre? Måske fandt du flere dubletter. Eller måske begyndte du at slå forskellige personer sammen. Et lavere antal er ikke bevis på bedre data. Målet er ikke færrest mulige profiler; det er de mest forsvarlige identiteter til formålet. Og hvert kriterium har en matchningsmetode: Exact, Exact Normalized eller Fuzzy med høj, mellem eller lav præcision. Salesforces egen advarsel er pointen: En mindre præcis metode øger konsolideringsgraden, »men kan give uønskede match«. (Fuzzy er ikke tilgængelig for felter på Account, og de normaliserede værdier bruges kun til sammenligningen; de gemmes ikke i den samlede profil, hvilket er harmoniseringstrinnet fra modul 3 i praksis: Identity Resolution Match Methods (opens in a new tab), på engelsk.) Jo løsere metoden er, jo mere bliver selve identiteten en vurdering. Hvis den er forkert, personaliserer vi så bare en side dårligt, eller viser vi én persons supporthistorik til en anden, eller lader vi en agent handle på to personers data?
Det er min holdning: Hvor streng matchningen skal være, er en risikobeslutning. Det afhænger af, hvor entydigt matchningsfelterne identificerer en person, og hvad et falsk match koster. Hvor det er dyrt at blande sammen, så undermatch med vilje. To profiler for én person er upraktisk. Én profil, der rummer to personer, kan være farlig.
Afstemning er stadig ikke mastering
Sektion kaldt “Afstemning er stadig ikke mastering ”Når profilerne er samlet, er kilderne stadig uenige: Salesforce siger Dallas, e-handel Plano, support Dallas. Hvad viser den samlede profil? Det afgør afstemningsregler (reconciliation rules): Last Updated, Most Frequent eller Source Priority (senest opdateret, hyppigste, kildeprioritet), sat pr. objekt og mulige at tilsidesætte pr. felt (Identity Resolution Reconciliation Rules (opens in a new tab), på engelsk). Det burde lyde som overlevelsesreglerne fra modul 3.
Her kommer teams i problemer. Den samlede profil viser Dallas, og nogen siger: »Fint, Dallas er vores gyldne værdi.« Ro på. E-handel siger stadig Plano. Salesforce siger klart, at afstemning ikke sletter eller ændrer kildedata eller opdaterer kildesystemerne, og den er ikke beregnet til at vælge en »bedste« værdi til hver applikation. Den afgør kun, hvad den samlede profil viser (samme kilde). Præsentation er ikke autoritet.
Eksamensviden. Kend, hvordan identitetsopløsning i Data 360 beslutter og viser: I en matchningsregel skal alle kriterier matche, og en hvilken som helst regel, der matcher, samler profilerne (flere kriterier for præcision, færre for konsolidering); de tre afstemningsregler er Last Updated, Most Frequent og Source Priority, sat pr. objekt og mulige at tilsidesætte pr. felt; og afstemning ændrer ikke kildedataene, og kontaktpunkter afstemmes ikke.
Kontaktpunkter gør pointen endnu tydeligere. En person kan have en privat og en arbejdsmail, en mobil og en fastnettelefon, alle legitime. Data 360 afstemmer slet ikke kontaktpunkter: Hver e-mail og hvert telefonnummer bliver på den samlede profil (samme kilde). Nogle gange er flere værdier simpelthen sandheden. »Samlet« betyder ikke én værdi for alting.
En golden record er en beslutning
Sektion kaldt “En golden record er en beslutning ”Sammenlign med et reelt masterkrav. Forretningen siger, at ERP’et er autoritativt for det juridiske navn, og masterværdien er »Oakline Logistics LLC«. Salesforce, fakturering og service skal alle bruge den, og hvis én er uenig, sender masterprocessen den styrede værdi tilbage. Det er en anden arkitektur. Vi vælger ikke, hvad ét billede viser; vi beslutter: Dette er den værdi, virksomheden bruger, og hvert deltagende system konvergerer mod den.
Altså: En samlet profil samler identiteter og oplysninger. En golden record er en styret beslutning om, hvilke værdier der er autoritative. En samlet profil kan give et fremragende samlet billede af kunden, bygget af autoritative kilder. Det gør den ikke til det system, der er master for kunden.
En samlet profil er et kort. En golden record er en beslutning.
Sporbarhed
Sektion kaldt “Sporbarhed ”Hvis den samlede profil siger Dallas, hvor kom det så fra: Salesforce, ERP’et, e-handel? Blev det valgt som senest opdateret, hyppigste, kildeprioritet? Den oprindelse er vigtig for revision, databeskyttelse, fejlsøgning, rettelse af datakvalitet og agenters beslutninger, og frem for alt for at vide, hvor en rettelse hører hjemme. Hvis Dallas er forkert, retter det ikke kilden at redigere det samlede billede. Du har brug for de eksterne id’er, identitetslinkene og felterne til dataoprindelse for at spore tilbage til den post, der skal ændres.
Tre værktøjer til tre opgaver
Sektion kaldt “Tre værktøjer til tre opgaver ”Sådan skiller jeg dem ad:
- Dubletstyring og sammenfletning, inden for én Salesforce-org, når der er en klar vinder, og du ikke længere har brug for dubletterne (modul 3).
- Identitetsopløsning i Data 360, til én identitet og ét samlet billede på tværs af kilder uden at ændre dem: et register.
- En dedikeret MDM-platform, når værdier skal besluttes én gang og sendes tilbage til hvert deltagende system: sameksistens eller centraliseret.
Tre værktøjer til tre opgaver: flet sammen, link, master.
Køb ikke MDM, når du har brug for et kort. »Vi vil have, at servicemedarbejderen kan se, at denne Salesforce-kunde er den samme person, der købte online« kræver måske identitetsopløsning og samlet kontekst, ikke centraliseret MDM. »ERP’et, Salesforce, e-handel og fakturering skal alle bruge det samme styrede juridiske navn, og ændringer skal flyde tilbage til dem alle« er noget andet: Det er mastering. Løs ikke det andet, når du har det første, og lad ikke, som om det første løste det andet.
Én identitet er ikke én tilladelse
Sektion kaldt “Én identitet er ikke én tilladelse ”Identitetsopløsning siger, at disse poster er én person. Det betyder ikke, at alle, der kan se én kildepost, må se alt, hvad der hænger på den samlede identitet. En detailpartner må se de leveringer, den selv har sendt; en anden partners leveringer til den samme modtager kommer den ikke ved, selv om identitetslaget ved, at de hænger sammen. Identitetsgrafen kan være rigtig, mens adgangsdesignet er forkert. At samle identiteter visker ikke sikkerhedsgrænser ud. Derfor bliver overmatchning et databeskyttelsesproblem, og derfor behandler Steve Trucking-kontrolpunktet det så varsomt at samle modtagere: Et kort over, hvem der er hvem, giver hverken ejerskab eller adgang.
Ud over eksamen: hvad AI ændrer. Agenter har brug for én identitet at handle ud fra, og den samlede profil giver dem den. Det hæver indsatsen begge veje. Overmatchning er nu en databeskyttelseshændelse: en agent, der handler for én person på en andens data. Og en agent, der »opdaterer kunden«, skal skrive til attributtens system of record ved hjælp af autoritetskortet fra modul 1, ikke til den samlede profil. Kortet fortæller agenten, hvem personen er; autoritetsmodellen fortæller den, hvor en ændring hører hjemme.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hvilket bevis der er nok til at samle profiler, og hvordan prisen for et falsk match bestemmer strengheden.
- Hvilke afstemningsregler der afgør, hvad den samlede profil viser.
- Om behovet er oprydning af dubletter i én org, identitet på tværs af kilder eller reel mastering for hele virksomheden.
- Hvilken kilde der forbliver autoritativ for hver attribut, også når Data 360 viser en afstemt værdi.
- Hvordan samlet identitet spiller sammen med sikkerhed, databeskyttelse, oprindelse og agenters handlinger.
Data 360 kan fortælle os, at disse profiler hører sammen, give os en samlet identitet, afstemme det, den viser, og beholde linkene tilbage til hver kilde. Det er enormt værdifuldt. Men hvis Salesforce siger én ting og ERP’et en anden, skal nogen stadig beslutte, hvilket system der må ændre virksomhedens sandhed. Så når nogen siger »vi har en samlet profil, så vi har vores golden record«, så spørg: Samlede vi dataene, eller masterede vi dem?
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
- Salesforce Help, Data 360: Identity Resolution Match Rules (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) og Identity Resolution Reconciliation Rules (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
