Masterdata och identitet
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)
Studieguide för kapitel 6 i kursen Data Architect. Läs de sex modulerna först, inklusive genomgången av Kontrollpunkt 1; den här sidan hjälper dig att kontrollera vad som har fastnat.
Om den här studieguiden. Den bygger enbart på kursens eget innehåll och på listan över mål i Salesforce publicerade provguide. Den bygger aldrig på riktiga provfrågor, och den påstår inte att den vet vad som kommer på provet. Om du har skrivit provet, skicka inte frågor från det till mig: certifieringsavtalet förbjuder att de delas, och att memorera svar är ändå fel sätt att bli arkitekt.
Det här kapitlet bär provets avsnitt Master Data Management (5 %) och den samlade bilden av kunden från Salesforce Data Management. Avsnittet är litet till vikten, men dess idéer (auktoritet, matchning, överlevnadsregler) dyker upp i många andra scenarier. Plattformens siffror ändras, så kontrollera de aktuella innan du förlitar dig på dem.
Inför provet
Section titled “Inför provet ”Bocka av dem allt eftersom. Varje punkt länkar till där den lärs ut.
MDM-2: en golden record och ett sanningssystem
- Jag vet att auktoritet tilldelas per attribut, inte per post: ett konto kan ha fält som hanteras som masterdata i ERP:t och fält som hanteras som masterdata i Salesforce. (Sanningen hör till ett attribut)
- Jag frågar var varje attribut skapas, redigeras och refereras, och hur snabbt det ändras (latens). (Skapas, redigeras, refereras, och hur snabbt?)
- Jag kan bygga en auktoritetskarta, och jag vet att affärsägaren och det auktoritativa systemet inte är samma sak. (Bygg en auktoritetskarta)
- Jag vet att auktoriteten kan ändras under livscykeln (ett prospekt i Salesforce blir en kund som styrs av ERP:t), och att en kopia inte är någon auktoritet. (Auktoriteten ändras under livscykeln, En kopia är ingen auktoritet)
MDM-1: tekniker för MDM
- Provkunskap: Jag känner till de fyra implementeringsstilarna för MDM, register, konsolidering, samexistens och centraliserad: vad var och en centraliserar och om den skickar tillbaka värden. (De fyra sida vid sida)
- Jag kan skilja de fyra MDM-stilarna åt: register, konsolidering, samexistens och centraliserad, och välja den lättaste som löser problemet. (De fyra sida vid sida)
- Jag vet att en kanonisk datamodell harmoniserar strukturen, men inte avgör auktoriteten. (En gemensam modell är inte en gemensam sanning)
- Jag känner till ordningen: harmonisera, matcha sedan, konsolidera sedan. (Harmonisera, matcha sedan, konsolidera sedan)
- Jag vet att trösklar speglar toleransen för fel, och att berikning behöver ett känt ursprung. (Trösklar, granskning och berikning)
- Provkunskap: Jag känner till hierarkihantering: Parent Account bygger hierarkin (vyn i Lightning visar upp till 2 000 konton, utan personkonton), hierarkier har ofta delad masterdata, och ett företag kan ha flera giltiga hierarkier. (Hierarkier är också masterdata, En hierarki, flera master)
MDM-3: att välja de vinnande attributen
- Jag håller isär matchning, sammanslagning och överlevnadsregler. (Matchning, sammanslagning och överlevnadsregler)
- Jag känner till överlevnadsreglerna: senaste, vanligaste, källprioritet, och att varje regel behöver en ägare. (Överlevnadsregler: vilket värde vinner?)
- Jag vet att en matchning inte kräver en sammanslagning, och jag slår bara samman när det finns en tydlig vinnare, efter att först ha bestämt vad som händer med barnposterna. (En matchning kräver ingen sammanslagning, Min regel för sammanslagning: en tydlig vinnare)
- Provkunskap: Jag vet vad en sammanslagning av konton i Salesforce gör: upp till tre poster, en huvudpost (principal), den äldsta postens Created By och Created Date behålls, de andra hamnar i papperskorgen (Recycle Bin), och kontaktpunktsobjekten slås inte samman för personkonton. (Vad en sammanslagning i Salesforce faktiskt gör)
SDM-3: en samlad bild av kunden
- Jag vet att identitetsupplösningen i Data 360 länkar källprofiler till en enhetlig profil och behåller länkarna tillbaka: närmast ett register. (Identitetsupplösning besvarar ”vem?”)
- Provkunskap: Jag känner till matchningsreglerna i Data 360: alla kriterier i en regel måste matcha, vilken regel som helst kan matcha; fler kriterier för precision, färre för konsolidering. (Matchningsregler)
- Jag känner till matchningsmetoderna (Exact, Exact Normalized, Fuzzy med tre precisionsnivåer): en mindre exakt metod höjer konsolideringen, och risken för felaktiga matchningar. (Matchningsregler)
- Provkunskap: Jag vet att avstämningsreglerna (Last Updated, Most Frequent, Source Priority) avgör vad den enhetliga profilen visar, men inte ändrar källorna; kontaktpunkter stäms inte av. (Avstämning är fortfarande inte masterdatahantering)
- Jag kan välja mellan dubbletthantering, identitetsupplösning och en dedikerad MDM-plattform för jobbet. (Tre verktyg för tre jobb)
MDM-4 och tvåvägsdata
- Jag vet att tvåvägsdata inte betyder två master: en redigering i Salesforce av ett fält som ERP:t äger är en begäran, så designa begäran → validering → acceptans → publicering, med ett väntande tillstånd. (Tvåvägsdata betyder inte två master, När mastern säger nej)
- Jag vet hur man undviker loopar och kollisioner: skilj en ursprunglig ändring från dess eko, och bestäm vilka fält som färdas tillsammans som en transaktion. (Loopar och kollisioner)
- För en kund i två ERP:er kan jag välja en hierarki, likställda konton eller ett konto med ett barn per ERP, utifrån hur väl klienten håller sina ERP:er synkade. (En kund, två ERP:er, Fråga hur de håller ERP:erna synkade)
Kontrollpunkt 1: att sätta ihop Del 1
- Provkunskap: Jag vet vilka externa licenser som har standarddelning: Customer Community Plus och Partner Community, som behöver roller för de externa användarna; Customer Community använder delningsuppsättningar (sharing sets). (Vem ser vad, och vem behöver en licens)
Bortom provet
Section titled “Bortom provet ”Provet är golvet, inte taket. Det här är vanorna från kapitlet som en arkitekt behöver, oavsett om någon fråga någonsin tar upp dem.
- ”En enda sanningskälla”: vilken sanning? Det är en sanningens arkitektur, inte en enda post.
- Gör auktoriteten synlig i schemat: ett prefix för fält som ett annat system äger.
- Förtroende kräver mer än ett värde: källa, senast bekräftad, vem som ändrade det.
- Börja med problemet, inte med MDM-produkten. MDM är ett affärsbeslut om auktoritet.
- Att länka är inte att hantera masterdata.
- Där felaktiga matchningar är dyra, matcha för lite med avsikt.
- Behåll dubbletter från externa laddningar när du kan behöva spåra bakåt.
- En enhetlig profil är en karta. En golden record är ett beslut.
- Presentation är inte auktoritet.
- Att förena identiteter suddar inte ut säkerhetsgränser.
- Det svåraste är de dubbelriktade flödena. Delad auktoritet är inte problemet; otydlig auktoritet är det.
- Låt aldrig en avvisad begäran bli en konkurrerande sanning.
- Ett fält som säger att det här är masterdata styr vad som går att redigera, inte en posttyp.
- Vi styr inte över ERP:erna. Vi styr hur vi representerar dem i Salesforce.
Ord att kunna
Section titled “Ord att kunna ”| Term | På en rad |
|---|---|
| Masterdatahantering (MDM) | Att fastställa och styra den auktoritativa identiteten och de auktoritativa värdena för nyckeldata över systemen |
| Auktoritetskarta | För varje attribut: vem som skapar det, vem som äger beslutet, vilket system som är auktoritativt, vem som får ändra det |
| Golden record | Ett styrt beslut om vilka värden som är auktoritativa |
| Hybrid golden record | En post där vissa attribut hanteras som masterdata någon annanstans och kopieras in, och vissa ägs lokalt |
| Register (registry) | MDM som länkar poster som samma entitet utan att ändra källorna |
| Konsolidering | MDM som kombinerar data centralt, oftast för analys, utan att skicka tillbaka något |
| Samexistens (coexistence) | MDM som bestämmer det masterhanterade värdet och publicerar tillbaka det till källorna |
| Centraliserad MDM | MDM där styrda data skapas i mastern och distribueras |
| Kanonisk datamodell | En överenskommen form för ett begrepp i hela företaget, som används för att mappa system mot varandra |
| Harmonisering | Att göra värden jämförbara: standardformat, koder och förkortningar |
| Matchning | Att avgöra om poster representerar samma sak |
| Överlevnadsregler (survivorship) | Regler för vilket värde som vinner när källorna är oense |
| Huvudpost (principal record) | Vid en sammanslagning i Salesforce: posten som överlever och behåller sina dolda och skrivskyddade fält |
| Matchningsmetod (match method) | Hur ett matchningskriterium i Data 360 jämför värden: exakt, exakt normaliserat eller fuzzy |
| Identitetsupplösning (identity resolution) | Matchningen i Data 360 av källprofiler till enhetliga profiler |
| Enhetlig profil | En uppsättning nycklar som länkar källposter som representerar en person eller ett företag |
| Avstämningsregler (reconciliation rules) | Regler i Data 360 för vilket värde en enhetlig profil visar |
| Hierarki med delad masterdata | En hierarki vars grenar ägs av olika system |
Testa dig själv
Section titled “Testa dig själv ”Korta scenarier i kursens stil. Bestäm ditt svar innan du öppnar det.
1. ”Salesforce är vår enda sanningskälla för kunden.” Vad frågar du?
Vilken sanning? Auktoritet gäller per attribut: ERP:t kanske äger det juridiska namnet, faktureringsadressen och kreditgränsen medan Salesforce äger kundansvarig säljare och kundnivå. Bygg en auktoritetskarta. Läs om Sanningen hör till ett attribut.
2. Serviceagenterna behöver se att en kontakt i Salesforce är samma person som köpte på nätet. Ingen behöver att systemen ändras. Vilken MDM-stil?
Ett register: länka posterna som en identitet utan att ändra källorna, vilket är vad identitetsupplösningen i Data 360 gör. Välj det lättaste mönstret som löser problemet. Läs om Register: säg vem som är vem.
3. Överlevnadsregeln är satt till ”senaste vinner” för varje fält. Någon ändrar kopian i Salesforce av det juridiska namnet som ERP:t äger. Vad händer, och vad är fel?
Det nyaste värdet vinner, och kopian kör över auktoriteten. ”Senaste” är ett uttalande om förtroende som passar vissa attribut (ett mobilnummer) och inte andra. Där auktoritetskartan säger att ERP:t äger fältet vinner ERP:t. Läs om Överlevnadsregler: vilket värde vinner?.
4. Kundposter från ett äldre system importeras och matchar befintliga konton. Ska de slås samman?
Var försiktig. En matchning kräver ingen sammanslagning, och en sammanslagning förstör de äldre ID:n och värden som du kan behöva spåra. Länka dem, om det inte finns en tydlig vinnare och dubbletten inte tillför något du behöver. Läs om Min regel för sammanslagning: en tydlig vinnare.
5. Den enhetliga profilen i Data 360 visar Dallas. Teamet säger att Dallas nu är det gyllene värdet för varje system. Är det så?
Nej. Avstämningen avgör vad den enhetliga profilen visar; den ändrar inte källorna och fattar inget beslut om masterdata. Om varje system måste använda ett styrt värde är det samexistens eller centraliserad MDM, med en ägare. Läs om Avstämning är fortfarande inte masterdatahantering.
6. Att matcha medicinska journaler kontra marknadsföringsposter: samma regler?
Nej. En felaktig matchning i marknadsföringen skickar fel erbjudande; i medicinska data kombinerar den två personers historik. Sätt striktheten efter vad det kostar att ha fel, och matcha för lite där sammanblandning är dyr. Läs om Vad det kostar att ha fel.
7. Säljarna vill uppdatera en faktureringsadress som ERP:t äger från Salesforce. Hur designar du det?
Som en begäran, inte en redigering: Salesforce skickar det föreslagna värdet, ERP:t validerar och accepterar det, och publicerar tillbaka det auktoritativa värdet. Håll ett väntande tillstånd tills dess, och hantera avvisningar, kollisioner och ekon. Läs om Tvåvägsdata betyder inte två master.
8. Hos Steve Trucking förekommer samma John Smith i två detaljhandelspartners manifest. Ska han förenas?
Nej, medvetet inte. En partner får aldrig se en annans mottagare, och en enhetlig identitet är bron som läcker. Matcha för lite där sammanblandning är dyr; om en partner vill känna igen återkommande mottagare, avgränsa det till just den partnern. Läs om Skulle jag förena mottagare över partnerna?.
9. En säljare skickar en ny gata för en adress som ERP:t äger medan någon i ERP:t, samma minut, ändrar orten. Vad bestämmer du?
Om adressen färdas som en transaktion. Om den gör det går alla fälten tillsammans eller inget av dem, och begäran avvisas eftersom adressen har ändrats under tiden. Bestäm det före den första kollisionen, och kom ihåg att begäran ber om att få ändra ERP:ts värde, inte ändrar det. Läs om Loopar och kollisioner.
10. En klient har samma kund i två ERP:er, och ingen håller de två posterna synkade. Försäljningen vill ha ett konto. Vad rekommenderar du?
Inte ett konto. Om de inte kan hålla posterna synkade i sina egna ERP:er kan Salesforce inte göra det åt dem: representera dem som likställda konton eller en hierarki, och visa den struktur som försäljningen redan känner till. Ett konto med ett barn per ERP kräver en klient som håller de gemensamma värdena synkade. Läs om Fråga hur de håller ERP:erna synkade.
Utforska vidare
Section titled “Utforska vidare ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-09-25): den officiella listan över mål och deras vikter. Kontrollera alltid den aktuella versionen innan du bokar provet.
- Varje moduls eget avsnitt Utforska vidare listar Salesforce-dokumentationen bakom dess fakta, med datum för kontrollen.