At linke er ikke at mastere

🌐 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)

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

Kapitel 6 i Data Architect, del 1: At blive dataarkitekt. Forrige: Datakvalitet og styring.

»Vi skal have én sandhedskilde.« Det er en af de mest gentagne sætninger i arkitektur og en af de mindst gennemtænkte. For hvad? Tag én konto. ERP’et ejer måske dens juridiske navn, fakturaadresse og kreditgrænse; Salesforce dens account executive og supportniveau; en samtykkeplatform dens markedsføringspræferencer. Tre autoriteter på én post, og det er helt normalt. Så når nogen siger »Salesforce er vores eneste sandhedskilde for kunden«, er mit næste spørgsmål altid: Hvilken sandhed?

Dette kapitel handler om at besvare det spørgsmål med vilje. Autoritet tildeles attribut for attribut. At linke poster er ikke at mastere dem. Og Salesforce giver dig forskellige værktøjer til forskellige opgaver: dubletstyring og sammenfletning inde i én org; identitetsopløsning i Data 360 til ét samlet billede på tværs af kilder; en dedikeret MDM-platform, når værdier skal besluttes én gang og sendes tilbage overalt. Kapitlet slutter med kontrolpunkt 1, hvor del 1 samles på Steve Trucking.

Billedet er genereret med AI.

Holdningerne i dette kapitel

• Sandhed pr. attribut. Spørg, hvor hver enkelt bid data oprettes, redigeres og refereres, og hvor hurtigt den ændrer sig. Vis ekstern autoritet i skemaet med et systempræfiks som sap_ eller erp_.
• Emner er anderledes. De lever i Salesforce, før ERP’et kender dem; ERP’ets autoritet gælder efter konverteringen.
• Register er normen på Salesforce-projekter, derefter konsolidering og sameksistens; ren centraliseret MDM er sjælden.
• Sammenflet kun, når der er en klar vinder. Behold dubletter fra eksterne indlæsninger, når du måske skal kunne spore tilbage; sammenfletning ødelægger den historik. Og beslut, hvad der sker med de underordnede poster: Flyt dem, lad være med at indlæse dem, eller behold dem på en inaktiv post.
• En samlet profil er et kort; en golden record er en beslutning. Det kan forvirre folk: Identitetsopløsning skaber et samlet individ, men ikke en golden record.
• Hvor streng matchningen skal være, er en risikobeslutning. Hvor det er dyrt at blande personer sammen, så undermatch med vilje.
• Tre værktøjer til tre opgaver: sammenfletning, identitetsopløsning, MDM.
• Hierarkier har delt mastering. Beslut autoriteten gren for gren.
• »Det sværeste er tovejsintegrationerne.« En tovejsintegration skaber ikke to mastere. Beslut, hvilke felter der følges ad som én transaktion, før den første kollision.
• Gør masterdata synlige. Et felt, der siger, at dette er masterdata (ERP’ets nøgle eller et flag), styrer redigerbarheden, ikke en posttype.
• Vi styrer ikke ERP’erne. Vi styrer, hvordan vi repræsenterer dem i Salesforce: Én kunde i to ERP’er er et hierarki, sideordnede konti eller én konto med en underordnet post pr. ERP, afgjort af, hvor godt klienten holder sine ERP’er synkroniseret.

Tre værktøjer til tre opgaver

Opgaven	Værktøjet	Hvad det gør ved kilderne
Dubletter inde i én org, med en klar vinder	Dubletstyring og sammenfletning	Fletter op til tre poster sammen; de andre ryger i papirkurven (Recycle Bin)
Én identitet og ét samlet billede på tværs af kilder	Identitetsopløsning i Data 360	Linker dem; ændrer ingen af dem (et register)
Én styret værdi, sendt tilbage til hvert system	En dedikeret MDM-platform	Beslutter værdien og distribuerer den (sameksistens eller centraliseret)

Vejen gennem dette kapitel

Seks moduler og en opgave, der hver især står på egne ben.

1. Én sandhedskilde pr. attribut. Autoritetskortet, den hybride golden record og tillidssignaler.
2. De fire måder at håndtere masterdata på. Register, konsolidering, sameksistens og centraliseret, og hvorfor en fælles model ikke er en fælles sandhed.
3. Matchning, sammenfletning og overlevelsesregler. Prisen for et falsk match, hvad en sammenfletning i Salesforce virkelig gør (og hvad der sker med de underordnede poster), og overlevelsesregler som en udtalelse om tillid.
4. Et kort er ikke en beslutning. Matchningsregler og matchningsmetoder, afstemningsregler, og hvorfor en samlet profil ikke er en golden record.
5. Når autoriteten er delt. Anmodninger kontra opdateringer, løkker og kollisioner, hierarkier med delt mastering og én kunde i to ERP’er.
6. Opgaven til kontrolpunkt 1, og derefter Kontrolpunkt 1: Steve Trucking, sådan ville jeg designe det. Prøv opgaven først: Tegn og forsvar designet fra del 1, sammenlign det så med mit, og se, hvad der ændrer sig i forhold til landskabet i kapitel 4.

Når du er færdig, så test dig selv med kapitlets studieguide: en tjekliste til eksamen, vanerne ud over den, ordene du skal kende og et par spørgsmål. Den afslutter del 1; studieguiden til del 1 samler alle seks kapitler.

Hvad en arkitekt beslutter her

• Hvilket system der er autoritativt for hver vigtig attribut, og hvordan det ses i modellen.
• Hvilken masterdatastil der passer til hvert datadomæne, og hvor meget autoritet masterlaget får.
• Hvornår der skal sammenflettes, og hvornår der skal linkes, og hvem der ejer hver overlevelsesregel.
• Hvor streng matchningen skal være, ud fra hvad et falsk match koster.
• Hvor tovejsdata og delte hierarkier har brug for eksplicitte grænser.

Ud over eksamen: Agenter har brug for én identitet at handle ud fra, og det hæver indsatsen begge veje. Overmatchning bliver til en databeskyttelseshændelse, og en agent, der »opdaterer kunden«, skal skrive til hver attributs system of record, ikke til den samlede profil. Hvert modul slutter med, hvad AI ændrer.

Læs mere

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
• Salesforce Help, Considerations for Merging Duplicate Accounts (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).

Næste: Del 2 begynder med Design til skala (coming soon).