Att länka är inte att hantera masterdata

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

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

Kapitel 6 i Data Architect, Del 1: Att bli dataarkitekt. Föregående: Datakvalitet och styrning.

”Vi behöver en enda sanningskälla.” Det är en av de mest upprepade fraserna inom arkitektur, och en av de minst granskade. För vad? Ta ett konto. ERP:t kanske äger det juridiska namnet, faktureringsadressen och kreditgränsen; Salesforce kundansvarig säljare och supportnivå; en samtyckesplattform marknadsföringspreferenserna. Tre auktoriteter på en post, och det är helt normalt. Så när någon säger ”Salesforce är vår enda sanningskälla för kunden” är min nästa fråga alltid: vilken sanning?

Det här kapitlet handlar om att besvara den frågan med avsikt. Auktoritet tilldelas attribut för attribut. Att länka poster är inte att hantera dem som masterdata. Och Salesforce ger dig olika verktyg för olika jobb: dubbletthantering och sammanslagning inom en org; identitetsupplösning i Data 360 för en samlad bild över flera källor; en dedikerad MDM-plattform när värden måste bestämmas en gång och skickas tillbaka överallt. Kapitlet avslutas med Kontrollpunkt 1, där Del 1 sammanförs i Steve Trucking.

Bilden är genererad med AI.

Hållningarna i det här kapitlet

• Sanning per attribut. Fråga var varje del av data skapas, redigeras och refereras, och hur snabbt den ändras. Visa extern auktoritet i schemat med ett systemprefix, som sap_ eller erp_.
• Prospekt är annorlunda. De finns i Salesforce innan ERP:t känner till dem; ERP:ts auktoritet gäller efter konverteringen.
• Register (registry) är normen i Salesforce-projekt, sedan konsolidering och samexistens; ren centraliserad MDM är ovanlig.
• Slå bara samman när det finns en tydlig vinnare. Behåll dubbletter från externa laddningar när du kan behöva spåra bakåt; en sammanslagning förstör den historiken. Och bestäm vad som händer med barnposterna: flytta dem, ladda inte in dem, eller behåll dem på en inaktiv post.
• En enhetlig profil är en karta; en golden record är ett beslut. Det här kan förvirra folk: identitetsupplösning skapar en enhetlig individ, men inte en golden record.
• Hur strikt matchningen är, är ett riskbeslut. Där en sammanblandning är dyr matchar du för lite med avsikt.
• Tre verktyg för tre jobb: sammanslagning, identitetsupplösning, MDM.
• Hierarkier har delad masterdata. Bestäm auktoriteten gren för gren.
• ”Det svåraste är de dubbelriktade flödena.” En tvåvägsintegration skapar inte två master. Bestäm vilka fält som färdas tillsammans som en transaktion innan den första kollisionen.
• Gör masterdata synliga. Ett fält som säger att det här är masterdata (ERP:ts nyckel eller en flagga) styr vad som går att redigera, inte en posttyp.
• Vi styr inte över ERP:erna. Vi styr hur vi representerar dem i Salesforce: en kund i två ERP:er blir en hierarki, likställda poster eller ett konto med ett barn per ERP, och valet avgörs av hur väl klienten håller sina ERP:er synkade.

Tre verktyg för tre jobb

Jobbet	Verktyget	Vad det gör med källorna
Dubbletter inom en org, med en tydlig vinnare	Dubbletthantering och sammanslagning	Slår samman upp till tre poster; de andra hamnar i papperskorgen (Recycle Bin)
En identitet och en samlad bild över flera källor	Identitetsupplösning i Data 360	Länkar dem; ändrar ingen av dem (ett register)
Ett styrt värde, som skickas tillbaka till varje system	En dedikerad MDM-plattform	Bestämmer värdet och distribuerar det (samexistens eller centraliserad)

Vägen genom kapitlet

Sex moduler och en uppgift, som var och en står på egna ben.

1. En sanningskälla per attribut. Auktoritetskartan, den hybrida golden record och förtroendesignaler.
2. De fyra sätten att hantera masterdata. Register, konsolidering, samexistens och centraliserad, och varför en gemensam modell inte är en gemensam sanning.
3. Matchning, sammanslagning och överlevnadsregler. Vad en felaktig matchning kostar, vad en sammanslagning i Salesforce verkligen gör (och vad som händer med barnposterna), och överlevnadsregler som ett uttalande om förtroende.
4. En karta är inget beslut. Matchningsregler och matchningsmetoder, avstämningsregler, och varför en enhetlig profil inte är en golden record.
5. När auktoriteten delas. Förfrågningar kontra uppdateringar, loopar och kollisioner, hierarkier med delad masterdata, och en kund i två ERP:er.
6. Uppgiften för Kontrollpunkt 1, sedan Kontrollpunkt 1: Steve Trucking, så skulle jag designa det. Gör uppgiften först: rita och försvara designen för Del 1, jämför den sedan med min, och se vad som ändras jämfört med landskapet i kapitel 4.

När du är klar kan du testa dig själv med kapitlets studieguide: en checklista inför provet, vanorna bortom det, orden att kunna och några frågor. Den avslutar Del 1; studieguiden för del 1 samlar alla sex kapitel.

Vad en arkitekt bestämmer här

• Vilket system som är auktoritativt för varje viktigt attribut, och hur det syns i modellen.
• Vilket sätt att hantera masterdata som passar varje datadomän, och hur mycket auktoritet masterdatalagret får.
• När du ska slå samman och när du ska länka, och vem som äger varje överlevnadsregel.
• Hur strikt matchningen ska vara, utifrån vad en felaktig matchning kostar.
• Var tvåvägsdata och delade hierarkier behöver uttryckliga gränser.

Bortom provet: agenter behöver en identitet att agera på, och det höjer insatserna åt båda hållen. Övermatchning blir en integritetsincident, och en agent som ”uppdaterar kunden” måste skriva till varje attributs system of record, inte till den enhetliga profilen. Varje modul avslutas med vad AI ändrar.

Utforska vidare

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) och Identity Resolution Reconciliation Rules (opens in a new tab) (på engelska, kontrollerad 2026-10-14).

Nästa: Del 2 börjar med Designa för skala (coming soon).