Datakvalitet og styring
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 5 i kurset Data Architect. Les de seks modulene først; 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 Data Governance (10 %) og deler av Data Modeling (metadata) og Salesforce Data Management (konsistens). Det er også her personvernlovgivningen møter datamodellen. Dette er arkitektur, ikke juridisk rådgivning: juridisk avdeling avgjør hva som gjelder, og arkitekten gjør det håndhevbart. 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.
GOV-2: å designe et styringsprogram
- Jeg vet at postens eier (en plattformmekanisme for tilgang) ikke er dataeieren (ansvarlig for dataene som en forretningsressurs), og at hvert felt kan registrere en Data Owner. (Postens eier er ikke dataeier)
- Jeg kan skille dataeieren (setter policyen), dataforvalteren (holder det i gang) og forvareren (drifter systemet) fra hverandre. (Eier, forvalter, forvarer)
- Eksamenskunnskap: Jeg kjenner de tre måtene å drive et styringsprogram på, sentralisert, føderert (desentralisert) og hybrid, og hva hver av dem betyr for hvem som setter policyen og hvor de felles definisjonene bor. (Slik drives programmet)
- Jeg kan bruke en RACI til å svare på hvor data opprettes, redigeres og refereres. (La RACI-en gjøre seg fortjent til plassen)
- Jeg kan nevne et håndhevingspunkt for en styringspolicy (tillatelser, validering, felt bare for integrasjonen, felthistorikk), ikke bare opplæring. (Styring må bli mekanisk)
- Jeg vet at kvalitetssignalene som er verdt å måle, er dem noen vil handle på. (Mål det noen vil handle på)
SDM-2 og MDM-4: å holde dårlige data ute
- Jeg kan avgjøre om oppretting av kontoer skal være åpen eller låst, og jeg kjenner veien med en foreløpig posttype for kontoer som forvaltes som masterdata i et ERP. (Åpent eller låst?, Mellomveien)
- Jeg kan beskytte styrte attributter (en ERP-ID, et juridisk navn) og samtidig la Salesforces egne felt være redigerbare: en hybrid golden record. Og jeg vet at et skrivebeskyttet felt på en side med Dynamic Forms ikke er håndheving; det er sikkerhet på feltnivå eller en valideringsregel. (Beskytt den styrte posten, En posttype for hver flyt)
- Jeg vet at toveisflyter er de vanskeligste: hvis ERP-et er master for et felt, ber Salesforce om å få endre det, og en kollisjon trenger en regel (ERP-et vinner, avvis hvis endret, eller et menneske løser det). (Beskytt den styrte posten)
- Jeg vet at obligatoriske felt kan skape falske data (
N/A,999999), og jeg kjenner alternativene. (Ikke la obligatoriske felt skape falske data) - Jeg kan avgjøre hva som skjer med innkommende data som ikke består kontrollene: godta, avvise eller sette i karantene, og hvem som eier unntaket. (Hver datagrense trenger en kvalitetsbeslutning)
- Jeg vet at referansedata også trenger metadata: definisjoner, en eier, en kilde og tilordninger mellom systemer. (Referansedata trenger også metadata)
DM-3: forretningsmetadata og teknisk metadata
- Eksamenskunnskap: Jeg kan skille forretningsmetadata (betydning, definisjoner, eier, regler, sensitivitet) fra teknisk metadata (objekter, felt, typer, API-navn, skjemaer, tilordninger, opphav). (To typer metadata)
- Jeg kjenner forskjellen mellom en forretningsordbok (hva det betyr), opphav (hvor det kom fra) og klassifisering (hvordan det må behandles). (Kjenn dataene dine)
- Jeg kjenner klassifiseringsfeltene i Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, på standardfelt og egendefinerte felt. (Klassifisering svarer på et annet spørsmål)
- Jeg vet at jeg skal klassifisere de sensitive feltene, ikke hvert felt, og at klassifisering uten håndheving er pynt. (Klassifisering uten håndheving er pynt)
GOV-1: personopplysninger og sensitive data
- Jeg kjenner igjen de viktigste lovene (GDPR, CCPA/CPRA, PIPEDA, LGPD, Australias Privacy Act, HIPAA, PCI DSS, SOX, COPPA), og jeg vet at GDPR kan omfatte virksomheter utenfor EU, og hva lovene har til felles: rettigheter, overføringer, varsling av brudd og ansvarlighet. (Regelverkene du bør kjenne igjen, Lover stopper ikke ved grensen)
- Jeg kjenner forskjellen mellom kryptering, maskering, pseudonymisering og anonymisering, og vet at pseudonymiserte opplysninger fortsatt er personopplysninger. (Anonymisert, pseudonymisert, kryptert, maskert)
- Jeg vet at å samle inn mindre er en personvernkontroll, og at oppbevaring designes på forhånd. (Å samle inn mindre er en arkitekturbeslutning, Oppbevaring er en del av modellen)
- Jeg kjenner samtykkedatamodellen: globalt samtykke på enkeltpersonen (Individual), samtykke per kanaltype, samtykke per kontaktpunkt, og formål med databruken (Data Use Purpose). (Bruk modellen Salesforce allerede har bygd)
- Jeg vet at forespørsler har frister (GDPR: én måned, kan forlenges med ytterligere to), så kartet over kopiene må finnes først. (Klokken går)
- Jeg vet at retten til å bli glemt betyr å finne hver kopi (historikk, arkiver, analyse, logger, filer, fritekst), og at policyene i Privacy Center kjøres per objekt mot en kundepost. (Så sier personen: glem meg, Privacy Center er et verktøy)
- Jeg kjenner avveiningene i Shield Platform Encryption: probabilistisk krypterte felt kan ikke filtreres, grupperes eller sorteres i SOQL; deterministisk kryptering tillater filtrering; krypterte felt kan ikke styre kriteriebasert deling. (Kryptering er en kontroll, ikke etterlevelse)
- Jeg vet at jeg ikke skal kopiere sensitive data fra produksjon inn i sandkasser, og at Data Mask erstattes av Data Mask & Seed. (Ikke kopier produksjonsrisikoen inn i sandkassen)
- Jeg kjenner sporing av felthistorikk (opptil 20 felt per objekt; 18 måneder, 24 bare gjennom API-et; for lange tekstfelt registreres bare redigeringen) kontra Field Audit Trail (opptil 200 felt, oppbevart til du sletter den). (Historikk er også data)
- Jeg kjenner oppbevaringstiden for logger i Event Monitoring (1 dag uten tilleggsproduktet for noen hendelser, 30 dager som standard med det, opptil 365 med utvidelse), og at hendelsene skal eksporteres til en SIEM før du trenger dem: betalte logger kan ikke hentes fra før kontrakten startet. (Revisjon og overvåking er ikke det samme)
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.
- En policy uten et håndhevingspunkt er stort sett et ønske.
- Eierne setter policyen; arkitektene håndhever den. Ikke finn på policyen, og ikke spill advokat.
- Styring blir aldri ferdig. Den går i bølger; design tilbakemeldingen.
- Ikke stol på god oppførsel. Bygg kontrollen: mennesker, integrasjoner og agenter gjør alle feil.
- Styr nok, ikke alt.
- Forebygg de dyre feilene først. Et duplikat med to års historikk er et stort problem.
- Skill mellom det mennesker leser og det maskiner tar beslutninger på.
- Dokumenter bredt; klassifiser bevisst.
- De billigste sensitive dataene å styre er de du aldri kopierte.
- Samtykke er data, og tillatelsen til å bruke data må kunne representeres som data.
- Kontroller først hvor personopplysningene havner, fordi sletting er sjelden og vanskelig.
- Etterlevelse er ikke et produkt.
- Fange inn → Klassifisere → Beskytte → Bruke → Oppbevare → Slette → Revidere.
- Fang opp dokumentasjonen før noen ber om den.
Ord du bør kunne
Section titled “Ord du bør kunne ”| Begrep | På én linje |
|---|---|
| Datastyring (data governance) | Policyene for data, og arkitekturen som gjør dem sanne |
| Dataeier | Personen eller funksjonen som har ansvaret for en type data |
| Dataforvalter (data steward) | Personen som holder dataene sunne fra dag til dag |
| Dataforvarer (custodian) | Teamet som drifter systemene som har dataene |
| RACI | Responsible, Accountable, Consulted, Informed (utfører, har ansvaret, rådføres, informeres) |
| Foreløpig post | En post opprettet før det autoritative systemet har godtatt den |
| Forretningsordbok | Omforente definisjoner av virksomhetens viktige begreper |
| Opphav (lineage) | Hvor en verdi kom fra, og hva som skjedde med den på veien |
| Dataklassifisering | Å merke data etter sensitivitet og compliance-kategori slik at de får riktige kontroller |
| Taksonomi | Settet med etiketter en organisasjon bruker til å klassifisere data |
| Personopplysninger | Opplysninger som identifiserer en person, eller kan knyttes tilbake til en |
| Pseudonymisering | Å bytte ut identifikatorer mens det fortsatt finnes en vei tilbake; fortsatt personopplysninger |
| Anonymisering | Å fjerne den rimelige muligheten til å identifisere personen |
| Samtykkedatamodell | Objektene i Salesforce for samtykke per person, kanal, kontaktpunkt og formål |
| Retten til å bli glemt | En persons rett, der loven gir den, til å få personopplysningene sine slettet |
| Hybrid golden record | Én post med mastersystemets felt og Salesforces egne felt, hver med én kilde |
| Forretningsmetadata / teknisk metadata | Hva dataene betyr og hvem som eier dem / hvordan de er bygd og beveger seg |
| Field Audit Trail | Lengre felthistorikk: opptil 200 felt per objekt, oppbevart til den slettes |
| Event Monitoring | Logger over innlogginger, eksporter, API-kall og visninger, oppbevart i begrenset tid |
| SIEM | Et sikkerhetslager der hendelseslogger oppbevares og analyseres |
Test deg selv
Section titled “Test deg selv ”Korte scenarioer i kursets stil. Bestem deg for svaret før du åpner det.
1. Policyen sier at bare økonomi kan endre en kundes juridiske navn. Teamet planlegger å ta det i opplæringen. Hva mangler?
Et håndhevingspunkt. Opplæring er ikke en kontroll: bruk tilgang på feltnivå, et felt som bare integrasjonen skriver til, en valideringsregel eller en kontrollert prosess. Eierne setter policyen; arkitekten gjør den mekanisk sann. Les Styring må bli mekanisk på nytt.
2. Kundene forvaltes som masterdata i ERP-et. Selgerne må kunne begynne å selge til nye prospekter med en gang. Hvordan lar du dem gjøre det, uten at to systemer oppretter masterposten?
La selgerne opprette kontoen med en foreløpig posttype, og konverter den så gjennom en kontrollert prosess: økonomi godkjenner, eller integrasjonen sender den til ERP-et, som matcher eller oppretter kunden og sender tilbake den autoritative ID-en. Les Mellomveien på nytt.
3. Et nytt obligatorisk felt fylles med «N/A» og «999999». Hva skjedde, og hva ville du gjort i stedet?
Brukerne ble tvunget til å svare før de visste svaret. Gjør feltet obligatorisk senere i prosessen, la et annet system levere verdien, bruk en foreløpig tilstand, eller tillat et eksplisitt Ukjent når det er et ekte svar. Les Ikke la obligatoriske felt skape falske data på nytt.
4. Teamet har byttet ut navn med tokener og sier at dataene er anonymisert, så sletteforespørselen er ferdigbehandlet. Er den det?
Ikke hvis tokenene kan kobles tilbake til personen: da er det pseudonymisering, og dataene er fortsatt personopplysninger. Si nøyaktig hva systemet gjør og hvor tilordningen ligger, og la juridisk avdeling avgjøre om det oppfyller kravet. Les Anonymisert, pseudonymisert, kryptert, maskert på nytt.
5. En mottaker sier ja til SMS om leveringer, men ikke til markedsføring. Hvordan bør modellen holde på det?
Med samtykkedatamodellen, ikke én avkrysningsboks: personen, kanalen (SMS), det bestemte nummeret og formålet med databruken (leveringsvarsler, ikke markedsføring). Og bestem hvilket system som er autoritativt for samtykke, slik at en tilbaketrekking når hvert system som handler på det. Les Bruk modellen Salesforce allerede har bygd på nytt.
6. Compliance må filtrere rapporter på et kryptert felt for amerikansk personnummer (Social Security Number). Feltet bruker standard krypteringsskjema. Hva er problemet?
Probabilistisk kryptering tillater ikke filtrering i SOQL-ledd som WHERE eller i filtre for datahåndtering. Deterministisk kryptering tillater filtrering mot en liten kostnad i styrke. Kryptering er en designbeslutning med avveininger, ikke en avkrysningsboks på slutten. Les Kryptering er en kontroll, ikke etterlevelse på nytt.
7. Seks måneder etter en hendelse spør noen hvem som eksporterte et sett med poster. Ingen satte opp lagring for Event Monitoring. Hva kan du fortelle dem?
Sannsynligvis ingenting: hendelseslogger oppbevares i begrenset tid (høyst ett år, selv med utvidelse), så alt som er eldre, er borte med mindre det ble eksportert. Sett opp Event Monitoring og send hendelsene til en SIEM før du trenger dem. Les Revisjon og overvåking er ikke det samme på nytt.
8. En selger ber Salesforce om å endre en kundes juridiske navn, som ERP-et er master for. I de samme minuttene endrer noen det i ERP-et. Hva bør designet si?
At Salesforce ba om endringen, ikke endret: ERP-et er master for feltet. Bestem kollisjonsregelen på forhånd (ERP-et vinner, avvis hvis verdien er endret, eller et menneske løser det), og om relaterte felt følger med samlet. Les Beskytt den styrte posten på nytt.
9. En persons forespørsel om sletting kommer inn. Teamet planlegger å begynne å kartlegge hvor dataene om personen ligger. Hva er problemet?
Klokken går allerede: etter GDPR én måned, som kan forlenges med ytterligere to for sammensatte anmodninger. Kartet over kopiene må finnes før forespørselen kommer. Les Klokken går 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 og lovene bak faktaene, med datoen de ble kontrollert.