Masterdata og identitet
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)
Studieguide til kapitel 6 i kurset Data Architect. Læs de seks moduler først, også gennemgangen af kontrolpunkt 1; denne side hjælper dig med at tjekke, hvad der har sat sig fast.
Om denne studieguide. Den bygger kun på kursets eget indhold og listen over mål i Salesforces offentliggjorte eksamensguide. Den bygger aldrig på rigtige eksamensspørgsmål, og den påstår ikke at vide, hvad der kommer til eksamen. Hvis du har taget eksamen, så send mig venligst ikke spørgsmål fra den: Certificeringsaftalen forbyder at dele dem, og at lære svar udenad er under alle omstændigheder den forkerte måde at blive arkitekt på.
Dette kapitel bærer eksamens afsnit Master Data Management (5 %) og det samlede billede af kunden fra Salesforce Data Management. Afsnittet vejer ikke meget, men dets idéer (autoritet, matchning, overlevelsesregler) dukker op inde i mange andre scenarier. Platformens tal ændrer sig, så tjek de aktuelle, før du stoler på dem.
Til eksamen
Sektion kaldt “Til eksamen ”Sæt flueben, efterhånden som du går frem. Hvert punkt linker til det sted, hvor det bliver undervist.
MDM-2: en golden record og et sandhedssystem
- Jeg ved, at autoritet tildeles pr. attribut, ikke pr. post: Én konto kan have felter, der er mastered i ERP’et, og felter, der er mastered i Salesforce. (Sandheden tilhører en attribut)
- Jeg spørger, hvor hver attribut oprettes, redigeres og refereres, og hvor hurtigt den ændrer sig. (Oprettet, redigeret, refereret, og hvor hurtigt?)
- Jeg kan bygge et autoritetskort, og jeg ved, at forretningsejeren og det autoritative system ikke er det samme. (Byg et autoritetskort)
- Jeg ved, at autoriteten kan skifte i løbet af livscyklussen (et emne i Salesforce bliver en kunde, der styres af ERP’et), og at en kopi ikke er autoritet. (Autoriteten skifter i løbet af livscyklussen, En kopi er ikke autoritet)
MDM-1: MDM-teknikker
- Eksamensviden: Jeg kender de fire implementeringsstile for MDM, register, konsolidering, sameksistens og centraliseret: hvad hver centraliserer, og om den sender værdier tilbage. (De fire side om side)
- Jeg kan skelne de fire MDM-stile fra hinanden: register, konsolidering, sameksistens og centraliseret, og vælge den letteste, der løser problemet. (De fire side om side)
- Jeg ved, at en kanonisk datamodel harmoniserer strukturen, men ikke afgør autoriteten. (En fælles model er ikke en fælles sandhed)
- Jeg kender rækkefølgen: harmonisér, så match, så konsolidér. (Harmonisér, så match, så konsolidér)
- Jeg ved, at tærskler afspejler tolerancen for fejl, og at berigelse kræver oprindelse. (Tærskler, gennemgang og berigelse)
- Eksamensviden: Jeg kender hierarkistyring: Parent Account bygger hierarkiet (visningen i Lightning viser op til 2.000 konti, uden personkonti), hierarkier har ofte delt mastering, og en virksomhed kan have flere gyldige hierarkier. (Hierarkier er også masterdata, Ét hierarki, flere mastere)
MDM-3: at vælge de vindende attributter
- Jeg holder matchning, sammenfletning og overlevelsesregler adskilt. (Matchning, sammenfletning og overlevelsesregler)
- Jeg kender overlevelsesreglerne: nyeste, hyppigste, kildeprioritet, og jeg ved, at hver regel har brug for en ejer. (Overlevelsesregler: hvilken værdi vinder?)
- Jeg ved, at et match ikke kræver en sammenfletning, og jeg fletter kun sammen med en klar vinder og beslutter først, hvad der sker med de underordnede poster. (Et match kræver ikke en sammenfletning, Min regel for sammenfletning: en klar vinder)
- Eksamensviden: Jeg ved, hvad en sammenfletning af konti i Salesforce gør: op til tre poster, én hovedpost, den ældste Created By og Created Date beholdes, de andre ryger i papirkurven (Recycle Bin), og kontaktpunktobjekter flettes ikke sammen for personkonti. (Hvad en sammenfletning i Salesforce faktisk gør)
SDM-3: et samlet billede af kunden
- Jeg ved, at identitetsopløsning i Data 360 linker kildeprofiler til en samlet profil og beholder linkene tilbage: tættest på et register. (Identitetsopløsning svarer på »hvem?«)
- Eksamensviden: Jeg kender matchningsregler i Data 360: Alle kriterier i en regel skal matche, en hvilken som helst regel kan matche; flere kriterier for præcision, færre for konsolidering. (Matchningsregler)
- Jeg kender matchningsmetoderne (Exact, Exact Normalized, Fuzzy med tre præcisionsniveauer): En mindre præcis metode øger konsolideringen og risikoen for falske match. (Matchningsregler)
- Eksamensviden: Jeg ved, at afstemningsregler (Last Updated, Most Frequent, Source Priority) afgør, hvad den samlede profil viser, men ikke ændrer kilderne; kontaktpunkter afstemmes ikke. (Afstemning er stadig ikke mastering)
- Jeg kan vælge mellem dubletstyring, identitetsopløsning og en dedikeret MDM-platform til opgaven. (Tre værktøjer til tre opgaver)
MDM-4 og tovejsdata
- Jeg ved, at tovejsdata ikke betyder to mastere: En redigering i Salesforce af et felt, som ERP’et ejer, er en anmodning, så designet er anmod → validér → acceptér → publicér, med en afventende tilstand. (Tovejsdata betyder ikke to mastere, Når masteren siger nej)
- Jeg ved, hvordan man undgår løkker og kollisioner: skelne en oprindelig ændring fra dens ekko og beslutte, hvilke felter der følges ad som én transaktion. (Løkker og kollisioner)
- For én kunde i to ERP’er kan jeg vælge et hierarki, sideordnede konti eller én konto med et barn pr. ERP, ud fra hvor godt klienten holder sine ERP’er synkroniseret. (Én kunde, to ERP’er, Spørg, hvordan de holder ERP’erne synkroniseret)
Kontrolpunkt 1: at samle del 1
- Eksamensviden: Jeg ved, hvilke eksterne licenser der har standarddeling: Customer Community Plus og Partner Community, som kræver roller til de eksterne brugere; Customer Community bruger sharing sets. (Hvem ser hvad, og hvem har brug for en licens)
Ud over eksamen
Sektion kaldt “Ud over eksamen ”Eksamen er gulvet, ikke loftet. Det her er de vaner fra dette kapitel, som en arkitekt har brug for, uanset om et spørgsmål nogensinde spørger til dem.
- »Én sandhedskilde«: Hvilken sandhed? Det er en arkitektur for sandhed, ikke én post.
- Gør autoriteten synlig i skemaet: et præfiks til felter, som et andet system ejer.
- Tillid kræver mere end en værdi: kilde, sidst bekræftet, hvem der ændrede den.
- Start med problemet, ikke med MDM-produktet. MDM er en forretningsbeslutning om autoritet.
- At linke er ikke at mastere.
- Hvor falske match er dyre, så undermatch med vilje.
- Behold dubletter fra eksterne indlæsninger, når du måske skal kunne spore tilbage.
- En samlet profil er et kort. En golden record er en beslutning.
- Præsentation er ikke autoritet.
- At samle identiteter visker ikke sikkerhedsgrænser ud.
- Det sværeste er tovejsintegrationerne. Delt autoritet er ikke problemet; tvetydig autoritet er.
- Lad aldrig en afvist anmodning blive til en konkurrerende sandhed.
- Et felt, der siger, at dette er masterdata, styrer redigerbarheden, ikke en posttype.
- Vi styrer ikke ERP’erne. Vi styrer, hvordan vi repræsenterer dem i Salesforce.
Ord du skal kende
Sektion kaldt “Ord du skal kende ”| Term | På én linje |
|---|---|
| Master data management (MDM) | At etablere og styre den autoritative identitet og de autoritative værdier for nøgledata på tværs af systemer |
| Autoritetskort | For hver attribut: hvem der opretter den, hvem der ejer beslutningen, hvilket system der er autoritativt, hvem der må ændre den |
| Golden record | En styret beslutning om, hvilke værdier der er autoritative |
| Hybrid golden record | En post, hvor nogle attributter er mastered et andet sted og kopieret ind, og nogle ejes lokalt |
| Register (registry) | MDM, der linker poster som den samme enhed uden at ændre kilderne |
| Konsolidering | MDM, der samler data centralt, som regel til analyse, uden at sende noget tilbage |
| Sameksistens (coexistence) | MDM, der beslutter masterværdien og publicerer den tilbage til kilderne |
| Centraliseret MDM | MDM, hvor styrede data oprettes i masteren og distribueres |
| Kanonisk datamodel | En aftalt form for et begreb på tværs af virksomheden, som bruges til at mappe systemer til hinanden |
| Harmonisering | At gøre værdier sammenlignelige: standardformater, koder og forkortelser |
| Matchning | At afgøre, om poster repræsenterer det samme |
| Overlevelsesregler (survivorship) | Regler for, hvilken værdi der vinder, når kilderne er uenige |
| Hovedpost (principal) | Ved en sammenfletning i Salesforce den post, der overlever og beholder sine skjulte og skrivebeskyttede felter |
| Matchningsmetode | Hvordan et matchningskriterium i Data 360 sammenligner værdier: præcist, præcist normaliseret eller fuzzy |
| Identitetsopløsning (identity resolution) | Data 360’s matchning af kildeprofiler til samlede profiler |
| Samlet profil | Et sæt nøgler, der linker kildeposter, som repræsenterer én person eller virksomhed |
| Afstemningsregler (reconciliation rules) | Regler i Data 360 for, hvilken værdi en samlet profil viser |
| Hierarki med delt mastering | Et hierarki, hvis grene ejes af forskellige systemer |
Test dig selv
Sektion kaldt “Test dig selv ”Korte scenarier i kursets stil. Beslut dig for dit svar, før du åbner det.
1. »Salesforce er vores eneste sandhedskilde for kunden.« Hvad spørger du om?
Hvilken sandhed? Autoritet er pr. attribut: ERP’et ejer måske det juridiske navn, fakturaadressen og kreditgrænsen, mens Salesforce ejer account executive og successniveau. Byg et autoritetskort. Læs Sandheden tilhører en attribut igen.
2. Servicemedarbejderne skal kunne se, at en Salesforce-kontakt er den samme person, der købte online. Ingen har brug for, at systemerne ændres. Hvilken MDM-stil?
Et register: Link posterne som én identitet uden at ændre kilderne, hvilket er det, identitetsopløsning i Data 360 gør. Vælg det letteste mønster, der løser problemet. Læs Register: fortæl mig, hvem der er hvem igen.
3. Overlevelsesreglen er sat til »nyeste vinder« for alle felter. Nogen ændrer Salesforces kopi af det juridiske navn, som ERP'et ejer. Hvad sker der, og hvad er galt?
Den nyeste værdi vinder, og kopien tilsidesætter autoriteten. »Nyeste« er en udtalelse om tillid, der passer til nogle attributter (et mobilnummer) og ikke til andre. Hvor autoritetskortet siger, at ERP’et ejer feltet, vinder ERP’et. Læs Overlevelsesregler: hvilken værdi vinder? igen.
4. Kundeposter fra et ældre system importeres og matcher eksisterende konti. Skal de flettes sammen?
Vær forsigtig. Et match kræver ikke en sammenfletning, og sammenfletning ødelægger de gamle id’er og ældre værdier, du måske skal spore. Link dem, medmindre der er en klar vinder, og dubletten ikke tilføjer noget, du har brug for. Læs Min regel for sammenfletning: en klar vinder igen.
5. Den samlede profil i Data 360 viser Dallas. Teamet siger, at Dallas nu er den gyldne værdi for alle systemer. Er den det?
Nej. Afstemning afgør, hvad den samlede profil viser; den ændrer ikke kilderne og træffer ikke en masterbeslutning. Hvis hvert system skal bruge én styret værdi, er det sameksistens- eller centraliseret MDM, med en ejer. Læs Afstemning er stadig ikke mastering igen.
6. Matchning af medicinske poster kontra markedsføringsposter: samme regler?
Nej. Et falsk match i markedsføring sender det forkerte tilbud; i medicinske data slår det to personers sygehistorik sammen. Sæt strengheden efter prisen for at tage fejl, og undermatch, hvor det er dyrt at blande sammen. Læs Prisen for at tage fejl igen.
7. Sælgerne vil opdatere en fakturaadresse, som ERP'et ejer, fra Salesforce. Hvordan designer du det?
Som en anmodning, ikke en redigering: Salesforce sender den foreslåede værdi, ERP’et validerer og accepterer den og publicerer den autoritative værdi tilbage. Hold en afventende tilstand indtil da, og håndtér afvisning, kollisioner og ekkoer. Læs Tovejsdata betyder ikke to mastere igen.
8. Hos Steve Trucking optræder den samme John Smith i to detailpartneres manifester. Skal han samles?
Nej, bevidst ikke. En partner må aldrig se en andens modtagere, og en samlet identitet er den bro, der lækker. Undermatch, hvor det er dyrt at blande sammen; hvis en partner vil have genkendelse af modtagere, der går igen, så afgræns det til den partner alene. Læs Ville jeg samle modtagere på tværs af partnere? igen.
9. En sælger sender en ny gade for en adresse, som ERP'et ejer, mens nogen i ERP'et i samme minut ændrer byen. Hvad beslutter du?
Om adressen følges ad som én transaktion. Hvis den gør, går felterne enten samlet eller slet ikke, og anmodningen afvises, fordi adressen er ændret i mellemtiden. Beslut det før den første kollision, og husk, at anmodningen beder om at ændre ERP’ets værdi, den ændrer den ikke. Læs Løkker og kollisioner igen.
10. En klient har én kunde i to ERP'er, og ingen holder de to poster synkroniseret. Salg vil have én konto. Hvad anbefaler du?
Ikke én konto. Hvis de ikke kan holde posterne synkroniseret i deres egne ERP’er, kan Salesforce ikke gøre det for dem: Repræsentér dem som sideordnede konti eller et hierarki, og vis den struktur, salg allerede kender. Én konto med et barn pr. ERP kræver en klient, der holder de fælles værdier synkroniseret. Læs Spørg, hvordan de holder ERP’erne synkroniseret igen.
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-09-25): den officielle liste over mål og deres vægtning. Tjek altid den aktuelle version, før du booker eksamen.
- Hvert moduls eget afsnit Læs mere angiver den Salesforce-dokumentation, der ligger bag dets fakta, med datoen for kontrollen.