Masterdata og identitet
Finnes også 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 · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Studieguide for kapittel 6 i kurset Data Architect. Les de seks modulene først, inkludert gjennomgangen av kontrollpunkt 1; denne siden hjelper deg å sjekke hva som satt seg.
Om denne studieguiden. Den bygger bare på kursets eget innhold og listen over mål i Salesforces publiserte eksamensguide. Den bygger aldri på ekte eksamensspørsmål, og den påstår ikke å vite hva som kommer på eksamen. Hvis du har tatt eksamen, ikke send meg spørsmål fra den: sertifiseringsavtalen forbyr å dele dem, og å pugge svar er uansett feil måte å bli arkitekt på.
Dette kapitlet dekker eksamens del Master Data Management (5 %) og den samlede visningen av kunden fra Salesforce Data Management. Det er en liten del målt i vekt, men idéene (autoritet, matching, overlevelsesregler) dukker opp i mange andre scenarioer. Tallene for plattformen endres, så sjekk de gjeldende før du stoler på dem.
Til eksamen
Section titled “Til eksamen ”Kryss av etter hvert. Hvert punkt lenker til der det undervises.
MDM-2: en golden record og et sannhetssystem
- Jeg vet at autoritet tildeles per attributt, ikke per post: én konto kan ha felt som mastres i ERP-systemet og felt som mastres i Salesforce. (Sannheten hører til et attributt)
- Jeg spør hvor hvert attributt opprettes, redigeres og refereres, og hvor raskt det endres. (Opprettet, redigert, referert, og hvor raskt?)
- Jeg kan bygge et autoritetskart, og jeg vet at forretningseieren og det autoritative systemet ikke er det samme. (Bygg et autoritetskart)
- Jeg vet at autoriteten kan endres gjennom livssyklusen (et prospekt i Salesforce blir en kunde styrt av ERP-systemet), og at en kopi ikke er autoritet. (Autoriteten endres gjennom livssyklusen, En kopi er ikke autoritet)
MDM-1: MDM-teknikker
- Eksamenskunnskap: Jeg kjenner de fire implementeringsstilene for MDM, register, konsolidering, sameksistens og sentralisert: hva hver av dem sentraliserer, og om den sender verdier tilbake. (De fire side om side)
- Jeg kan skille de fire MDM-stilene: register, konsolidering, sameksistens og sentralisert, og velge den letteste som løser problemet. (De fire side om side)
- Jeg vet at en kanonisk datamodell harmoniserer strukturen, men ikke avgjør autoriteten. (En felles modell er ikke en felles sannhet)
- Jeg kjenner rekkefølgen: harmoniser, så match, så konsolider. (Harmoniser, så match, så konsolider)
- Jeg vet at terskler gjenspeiler toleransen for feil, og at beriking trenger opphav. (Terskler, gjennomgang og beriking)
- Eksamenskunnskap: Jeg kjenner hierarkihåndtering: Parent Account bygger hierarkiet (visningen i Lightning viser opptil 2 000 kontoer, uten personkontoer), hierarkier har ofte delt mastring, og et selskap kan ha flere gyldige hierarkier. (Hierarkier er også masterdata, Ett hierarki, flere mastere)
MDM-3: å velge attributtene som vinner
- Jeg holder matching, sammenslåing og overlevelsesregler fra hverandre. (Matching, sammenslåing og overlevelsesregler)
- Jeg kjenner overlevelsesreglene: nyeste, hyppigste, kildeprioritet, og at hver regel trenger en eier. (Overlevelsesregler: hvilken verdi vinner?)
- Jeg vet at en match ikke krever en sammenslåing, og jeg slår bare sammen når det finnes en klar vinner, og bestemmer først hva som skjer med barna. (En match krever ikke en sammenslåing, Min regel for sammenslåing: en klar vinner)
- Eksamenskunnskap: Jeg vet hva en sammenslåing av kontoer i Salesforce gjør: opptil tre poster, én hovedpost, den eldste Created By og Created Date beholdes, de andre går til papirkurven, og contact point-objekter slås ikke sammen for personkontoer. (Hva en sammenslåing i Salesforce faktisk gjør)
SDM-3: én samlet visning av kunden
- Jeg vet at identitetsoppløsning i Data 360 kobler kildeprofiler til en samlet profil og beholder koblingene tilbake: nærmest et register. (Identitetsoppløsning svarer på «hvem?»)
- Eksamenskunnskap: Jeg kjenner samsvarsreglene i Data 360: alle kriteriene i en regel må matche, en hvilken som helst regel kan matche; flere kriterier for nøyaktighet, færre for konsolidering. (Samsvarsregler)
- Jeg kjenner samsvarsmetodene (Exact, Exact Normalized, Fuzzy med tre presisjonsnivåer): en mindre presis metode øker konsolideringen, og risikoen for falske matcher. (Samsvarsregler)
- Eksamenskunnskap: Jeg vet at avstemmingsregler (Last Updated, Most Frequent, Source Priority) avgjør hva den samlede profilen viser, men ikke endrer kildene; kontaktpunkter avstemmes ikke. (Avstemming er fortsatt ikke mastring)
- Jeg kan velge mellom duplikathåndtering, identitetsoppløsning og en egen MDM-plattform til jobben. (Tre verktøy for tre jobber)
MDM-4 og toveisdata
- Jeg vet at toveisdata ikke betyr to mastere: en redigering i Salesforce av et felt som ERP-systemet eier, er en forespørsel, så jeg designer forespørsel → validering → godkjenning → publisering, med en ventende tilstand. (Toveisdata betyr ikke to mastere, Når masteren sier nei)
- Jeg vet hvordan jeg unngår løkker og kollisjoner: skill en endring som starter et sted fra ekkoet av den, og bestem hvilke felt som reiser sammen som én transaksjon. (Løkker og kollisjoner)
- For én kunde i to ERP-systemer kan jeg velge et hierarki, likestilte kontoer eller én konto med et barn per ERP-system, ut fra hvor godt klienten holder ERP-systemene sine synkronisert. (Én kunde, to ERP-systemer, Spør hvordan de holder ERP-systemene synkronisert)
Kontrollpunkt 1: å sette sammen del 1
- Eksamenskunnskap: Jeg vet hvilke eksterne lisenser som har standard deling: Customer Community Plus og Partner Community, som trenger roller for de eksterne brukerne; Customer Community bruker sharing sets. (Hvem ser hva, og hvem trenger en lisens)
Utover eksamen
Section titled “Utover eksamen ”Eksamen er gulvet, ikke taket. Dette er vanene fra dette kapitlet som en arkitekt trenger, enten et spørsmål noen gang spør om dem eller ikke.
- «Én sannhetskilde»: hvilken sannhet? Det er en arkitektur for sannhet, ikke én post.
- Gjør autoriteten synlig i skjemaet: et prefiks for felt som et annet system eier.
- Tillit krever mer enn en verdi: kilde, sist bekreftet, hvem som endret den.
- Start med problemet, ikke MDM-produktet. MDM er en forretningsbeslutning om autoritet.
- Å koble er ikke å mastre.
- Der falske matcher er kostbare, match for lite med vilje.
- Behold duplikater fra eksterne innlastinger når du kan få bruk for å spore tilbake.
- En samlet profil er et kart. En golden record er en beslutning.
- Visning er ikke autoritet.
- Å samle identitet visker ikke ut sikkerhetsgrenser.
- Det vanskeligste er toveisflytene. Delt autoritet er ikke problemet; uklar autoritet er det.
- La aldri en avvist forespørsel bli en konkurrerende sannhet.
- Et felt som sier at dette er masterdata, styrer hva som kan redigeres, ikke en posttype.
- Vi kontrollerer ikke ERP-systemene. Vi kontrollerer hvordan vi representerer dem i Salesforce.
Ord du bør kunne
Section titled “Ord du bør kunne ”| Begrep | På én linje |
|---|---|
| Masterdatahåndtering (MDM) | Å etablere og styre den autoritative identiteten og verdiene til nøkkeldata på tvers av systemer |
| Autoritetskart | For hvert attributt: hvem oppretter det, hvem eier beslutningen, hvilket system er autoritativt, hvem kan endre det |
| Golden record | En styrt beslutning om hvilke verdier som er autoritative |
| Hybrid golden record | En post der noen attributter mastres et annet sted og kopieres inn, og noen eies lokalt |
| Register (registry) | MDM som kobler poster som samme enhet uten å endre kildene |
| Konsolidering | MDM som samler data sentralt, vanligvis for analyse, uten å sende noe tilbake |
| Sameksistens (coexistence) | MDM som avgjør den mastrede verdien og publiserer den tilbake til kildene |
| Sentralisert MDM | MDM der styrte data opprettes i masteren og distribueres |
| Kanonisk datamodell | En avtalt form for et begrep i virksomheten, brukt til å mappe systemer mot hverandre |
| Harmonisering | Å gjøre verdier sammenlignbare: standardformater, koder og forkortelser |
| Matching | Å avgjøre om poster representerer det samme |
| Overlevelsesregler (survivorship) | Regler for hvilken verdi som vinner når kildene er uenige |
| Hovedpost (principal record) | I en sammenslåing i Salesforce: posten som overlever og beholder de skjulte og skrivebeskyttede feltene sine |
| Samsvarsmetode (match method) | Hvordan et samsvarskriterium i Data 360 sammenligner verdier: eksakt, eksakt normalisert eller fuzzy |
| Identitetsoppløsning (identity resolution) | Matchingen i Data 360 av kildeprofiler til samlede profiler |
| Samlet profil | Et sett nøkler som kobler kildeposter som representerer én person eller ett selskap |
| Avstemmingsregler | Regler i Data 360 for hvilken verdi en samlet profil viser |
| Hierarki med delt mastring | Et hierarki der grenene eies av forskjellige systemer |
Test deg selv
Section titled “Test deg selv ”Korte scenarioer i kursets stil. Bestem deg for svaret før du åpner det.
1. «Salesforce er vår eneste sannhetskilde for kunden.» Hva spør du om?
Hvilken sannhet? Autoritet er per attributt: ERP-systemet kan eie det juridiske navnet, fakturaadressen og kredittgrensen mens Salesforce eier kundeansvarlig og kundesuksessnivå. Bygg et autoritetskart. Les Sannheten hører til et attributt på nytt.
2. Serviceagenter må kunne se at en kontakt i Salesforce er samme person som handlet på nett. Ingen trenger at systemene endres. Hvilken MDM-stil?
Et register: koble postene som én identitet uten å endre kildene, og det er det identitetsoppløsning i Data 360 gjør. Velg det letteste mønsteret som løser problemet. Les Register: fortell meg hvem som er hvem på nytt.
3. Overlevelsesreglene er satt til «nyeste vinner» for hvert felt. Noen endrer kopien i Salesforce av det juridiske navnet som ERP-systemet eier. Hva skjer, og hva er galt?
Den nyeste verdien vinner, og kopien overstyrer autoriteten. «Nyeste» er et utsagn om tillit som passer for noen attributter (et mobilnummer) og ikke for andre. Der autoritetskartet sier at ERP-systemet eier feltet, vinner ERP-systemet. Les Overlevelsesregler: hvilken verdi vinner? på nytt.
4. Kundeposter fra et gammelt system importeres og matcher eksisterende kontoer. Slå dem sammen?
Vær forsiktig. En match krever ikke en sammenslåing, og sammenslåing ødelegger de gamle ID-ene og eldre verdiene du kan få bruk for å spore. Koble dem, med mindre det finnes en klar vinner og duplikatet ikke tilfører noe du trenger. Les Min regel for sammenslåing: en klar vinner på nytt.
5. Den samlede profilen i Data 360 viser Dallas. Teamet sier at Dallas nå er den gylne verdien for hvert system. Er den det?
Nei. Avstemming avgjør hva den samlede profilen viser; den endrer ikke kildene eller tar en mastringsbeslutning. Hvis hvert system må bruke én styrt verdi, er det sameksistens eller sentralisert MDM, med en eier. Les Avstemming er fortsatt ikke mastring på nytt.
6. Matching av medisinske poster kontra markedsføringsposter: samme regler?
Nei. En falsk match i markedsføring sender feil tilbud; i medisinske data kombinerer den to menneskers sykehistorikk. Sett strengheten etter hva det koster å ta feil, og match for lite der sammenblanding er kostbart. Les Hva det koster å ta feil på nytt.
7. Selgerne vil oppdatere en fakturaadresse som ERP-systemet eier, fra Salesforce. Hvordan designer du det?
Som en forespørsel, ikke en redigering: Salesforce sender den foreslåtte verdien, ERP-systemet validerer og godtar den, og publiserer den autoritative verdien tilbake. Hold en ventende tilstand til da, og håndter avvisning, kollisjoner og ekkoer. Les Toveisdata betyr ikke to mastere på nytt.
8. Hos Steve Trucking dukker samme John Smith opp i manifestene til to detaljhandelspartnere. Samle ham?
Nei, bevisst ikke. En partner må aldri se en annens mottakere, og en samlet identitet er broen som lekker. Match for lite der sammenblanding er kostbart; hvis en partner vil kjenne igjen mottakere som kommer tilbake, avgrens det til bare den partneren. Les Ville jeg samlet mottakere på tvers av partnere? på nytt.
9. En selger sender en ny gateadresse for en adresse som ERP-systemet eier, mens noen i ERP-systemet samme minutt endrer byen. Hva bestemmer du?
Om adressen reiser som én transaksjon. Gjør den det, går feltene sammen eller ingen av dem, og forespørselen avvises fordi adressen ble endret i mellomtiden. Bestem det før den første kollisjonen, og husk at forespørselen ber om å endre ERP-systemets verdi, den endrer den ikke. Les Løkker og kollisjoner på nytt.
10. En klient har én kunde i to ERP-systemer, og ingen holder de to postene synkronisert. Salg vil ha én konto. Hva anbefaler du?
Ikke én konto. Hvis de ikke klarer å holde postene synkronisert i sine egne ERP-systemer, kan ikke Salesforce gjøre det for dem: representer dem som likestilte kontoer eller et hierarki, og vis strukturen salg allerede kjenner. Én konto med et barn per ERP-system krever en klient som holder de delte verdiene synkronisert. Les Spør hvordan de holder ERP-systemene synkronisert på nytt.
Les mer
Section titled “Les mer ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-09-25): den offisielle listen over mål og vektingen av dem. Sjekk alltid gjeldende versjon før du bestiller eksamen.
- Hver moduls egen Les mer-del lister opp Salesforce-dokumentasjonen bak faktaene, med datoen de ble kontrollert.