Datakvalitet og styring

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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — Billedet er lavet med AI

Studieguide til kapitel 5 i kurset Data Architect. Læs de seks moduler først; 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 Data Governance (10 %) og dele af Data Modeling (metadata) og Salesforce Data Management (konsistens). Det er også her, databeskyttelseslovgivningen møder datamodellen. Det her er arkitektur, ikke juridisk rådgivning: Jura afgør, hvad der gælder, og arkitekten gør det håndhæveligt. Platformens tal ændrer sig, så tjek de aktuelle, før du stoler på dem.

Til eksamen

Sæt flueben, efterhånden som du går frem. Hvert punkt linker til det sted, hvor det bliver undervist.

GOV-2: at designe et styringsprogram

Jeg ved, at postens ejer (en platformmekanisme til adgang) ikke er dataejeren (som står til ansvar for dataene som et forretningsaktiv), og at hvert felt kan registrere en Data Owner. (Postens ejer er ikke dataejeren)
Jeg kan skelne mellem dataejeren (fastsætter politikken), dataforvalteren (holder det kørende) og datavogteren (driver systemet). (Ejer, forvalter, vogter)
Eksamensviden: Jeg kender de tre måder at køre et styringsprogram på, centraliseret, fødereret (decentraliseret) og hybrid, og hvad hver af dem betyder for, hvem der fastsætter politikken, og hvor de fælles definitioner bor. (Sådan kører programmet)
Jeg kan bruge en RACI til at svare på, hvor data oprettes, redigeres og refereres. (Lad RACI’en gøre sig fortjent til sin plads)
Jeg kan nævne et håndhævelsespunkt for en styringspolitik (tilladelser, validering, felter kun for integrationen, felthistorik), ikke kun oplæring. (Styring skal blive mekanisk)
Jeg ved, at de kvalitetssignaler, der er værd at måle, er dem, nogen vil handle på. (Mål det, nogen vil handle på)

SDM-2 og MDM-4: at holde dårlige data ude

Jeg kan afgøre, om oprettelse af konti skal være åben eller låst, og jeg kender vejen med en foreløbig posttype for konti, der er mastered i et ERP. (Åben eller låst?, Mellemvejen)
Jeg kan beskytte styrede attributter (et ERP-id, et juridisk navn) og samtidig lade Salesforces egne felter være redigerbare: en hybrid golden record. Og jeg ved, at et skrivebeskyttet felt på en side med Dynamic Forms ikke er håndhævelse; det er sikkerhed på feltniveau eller en valideringsregel. (Beskyt den styrede post, En posttype til hvert flow)
Jeg ved, at tovejsflows er de sværeste: Hvis ERP’et er master for et felt, beder Salesforce om at ændre det, og en kollision har brug for en regel (ERP’et vinder, afvis, hvis værdien er ændret, eller et menneske løser det). (Beskyt den styrede post)
Jeg ved, at påkrævede felter kan skabe falske data (N/A, 999999), og jeg kender alternativerne. (Lad ikke påkrævede felter skabe falske data)
Jeg kan afgøre, hvad der sker med indgående data, der fejler tjek: acceptér, afvis eller sæt i karantæne, og hvem der ejer undtagelsen. (Hver datagrænse har brug for en kvalitetsbeslutning)
Jeg ved, at referencedata også har brug for metadata: definitioner, en ejer, en kilde og mappings mellem systemer. (Referencedata har også brug for metadata)

DM-3: forretningsmetadata og tekniske metadata

Eksamensviden: Jeg kender forskel på forretningsmetadata (betydning, definitioner, ejer, regler, følsomhed) og tekniske metadata (objekter, felter, typer, API-navne, skemaer, mappings, dataoprindelse). (To slags metadata)
Jeg kender forskellen på en forretningsordbog (hvad dataene betyder), dataoprindelse (hvor de kom fra) og klassifikation (hvordan de skal behandles). (Kend dine data)
Jeg kender Salesforces klassifikationsfelter: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, på standardfelter og brugerdefinerede felter. (Klassifikation besvarer et andet spørgsmål)
Jeg ved, at jeg skal klassificere de følsomme felter, ikke alle felter, og at klassifikation uden håndhævelse er pynt. (Klassifikation uden håndhævelse er pynt)

GOV-1: personoplysninger og følsomme data

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.

En politik uden et håndhævelsespunkt er for det meste et ønske.
Ejerne fastsætter politikken; arkitekterne håndhæver den. Opfind ikke politikken, og spil ikke jurist.
Styring bliver aldrig færdig. Den går i bølger; design feedbacken.
Stol ikke på god opførsel. Byg kontrollen: Mennesker, integrationer og agenter laver alle fejl.
Styr nok, ikke alt.
Forebyg de dyre fejl først. En dublet med to års historik er et stort problem.
Skeln mellem det, mennesker læser, og det, maskiner træffer beslutninger ud fra.
Dokumentér bredt; klassificér bevidst.
De billigste følsomme data at styre er dem, du aldrig kopierede.
Samtykke er data, og tilladelsen til at bruge data skal kunne repræsenteres som data.
Styr først, hvor personoplysningerne havner, for sletning er sjælden og svær.
Compliance er ikke et produkt.
Indsaml → Klassificér → Beskyt → Brug → Opbevar → Slet → Revidér.
Opsaml dokumentationen, før nogen beder om den.

Ord du skal kende

Term	På én linje
Datastyring (data governance)	Politikkerne for data og den arkitektur, der gør dem sande
Dataejer	Den person eller funktion, der står til ansvar for en type data
Dataforvalter (data steward)	Den person, der holder dataene sunde i det daglige
Datavogter (custodian)	Teamet, der driver systemerne, som rummer dataene
RACI	Responsible, Accountable, Consulted, Informed (udførende, ansvarlig, konsulteret, informeret)
Foreløbig post	En post, der er oprettet, før det autoritative system har accepteret den
Forretningsordbog	Aftalte definitioner af forretningens vigtige begreber
Dataoprindelse (lineage)	Hvor en værdi kom fra, og hvad der skete med den på vejen
Dataklassifikation	Mærkning af data efter følsomhed og compliance-kategori, så de får de rette kontroller
Taksonomi	Det sæt betegnelser, en organisation bruger til at klassificere data
Personoplysninger	Oplysninger, der identificerer en person eller kan kobles tilbage til en
Pseudonymisering	At erstatte identifikatorer, mens der stadig findes en vej tilbage; stadig personoplysninger
Anonymisering	At fjerne den rimelige mulighed for at identificere personen
Datamodel for samtykke	Salesforces objekter til samtykke pr. person, kanal, kontaktpunkt og formål
Retten til at blive glemt	En persons ret, hvor loven giver den, til at få sine personoplysninger slettet
Hybrid golden record	Én post med mastersystemets felter og Salesforces egne felter, hver med én kilde
Forretningsmetadata / tekniske metadata	Hvad dataene betyder, og hvem der ejer dem / hvordan de er bygget og bevæger sig
Field Audit Trail	Længere felthistorik: op til 200 felter pr. objekt, gemt, indtil den slettes
Event Monitoring	Logs over logins, eksporter, API-kald og visninger, gemt i begrænset tid
SIEM	Et sikkerhedslager, hvor hændelseslogs gemmes og analyseres

Test dig selv

Korte scenarier i kursets stil. Beslut dig for dit svar, før du åbner det.

1. Politikken siger, at kun økonomi må ændre en kundes juridiske navn. Teamet planlægger at dække det i oplæringen. Hvad mangler der?

Et håndhævelsespunkt. Oplæring er ikke en kontrol: Brug adgang på feltniveau, et felt, som kun integrationen skriver, en valideringsregel eller en kontrolleret proces. Ejerne fastsætter politikken; arkitekten gør den mekanisk sand. Læs Styring skal blive mekanisk igen.

2. Kunderne er mastered i ERP'et. Sælgerne skal kunne begynde at sælge til nye emner med det samme. Hvordan lader du dem gøre det, uden at to systemer opretter masterposten?

Lad sælgerne oprette kontoen som en foreløbig posttype, og konvertér den så via en kontrolleret proces: Økonomi godkender, eller integrationen sender den til ERP’et, som matcher eller opretter kunden og sender det autoritative id tilbage. Læs Mellemvejen igen.

3. Et nyt påkrævet felt fyldes med »N/A« og »999999«. Hvad skete der, og hvad ville du gøre i stedet?

Brugerne blev tvunget til at svare, før de kendte svaret. Kræv det senere i processen, lad et andet system levere det, brug en foreløbig tilstand, eller tillad et eksplicit Unknown (ukendt), når det er et reelt svar. Læs Lad ikke påkrævede felter skabe falske data igen.

4. Teamet har erstattet navne med tokens og siger, at dataene er anonymiseret, så anmodningen om sletning er klaret. Er den det?

Ikke hvis tokens kan kobles tilbage til personen: Det er pseudonymisering, og dataene er stadig personoplysninger. Sig præcis, hvad systemet gør, og hvor mappingen ligger, og lad jura afgøre, om det opfylder kravet. Læs Anonymiseret, pseudonymiseret, krypteret, maskeret igen.

5. En modtager siger ja til sms'er om leveringer, men ikke til markedsføring. Hvordan skal modellen rumme det?

Med datamodellen for samtykke, ikke ét afkrydsningsfelt: personen, kanalen (sms), det specifikke nummer og formålet med databrugen (leveringsbeskeder, ikke markedsføring). Og beslut, hvilket system der er autoritativt for samtykke, så en tilbagetrækning når frem til hvert system, der handler på det. Læs Brug den model, Salesforce allerede har bygget igen.

6. Compliance skal filtrere rapporter på et krypteret felt med et amerikansk personnummer (Social Security). Feltet bruger standardkrypteringsskemaet. Hvad er problemet?

Probabilistisk kryptering tillader ikke filtrering i SOQL-klausuler med WHERE eller i filtre til datahåndtering. Deterministisk kryptering tillader filtrering mod en lille pris i styrke. Kryptering er en designbeslutning med afvejninger, ikke et afkrydsningsfelt til sidst. Læs Kryptering er en kontrol, ikke compliance igen.

7. Seks måneder efter en hændelse spørger nogen, hvem der eksporterede et sæt poster. Ingen har sat lagring op til Event Monitoring. Hvad kan du fortælle dem?

Sandsynligvis ingenting: Hændelseslogs gemmes i begrænset tid (højst et år, selv med forlængelse), så alt, der er ældre, er væk, medmindre det blev eksporteret. Sæt Event Monitoring op, og send hændelserne til et SIEM, før du har brug for dem. Læs Revision og overvågning er ikke det samme igen.

8. En sælger beder Salesforce om at ændre en kundes juridiske navn, som ERP'et er master for. I de samme minutter ændrer nogen det i ERP'et. Hvad skal designet sige?

At Salesforce bad om en ændring, men ikke ændrede noget: ERP’et er master for feltet. Beslut kollisionsreglen på forhånd (ERP’et vinder, afvis, hvis værdien er ændret, eller et menneske løser det), og om relaterede felter følges ad. Læs Beskyt den styrede post igen.

9. En persons anmodning om sletning kommer ind. Teamet planlægger at begynde at kortlægge, hvor personens data bor. Hvad er problemet?

Uret tikker allerede: efter GDPR en måned, som kan forlænges med yderligere to ved komplekse anmodninger. Kortet over kopierne skal findes, før anmodningen kommer. Læs Uret tikker igen.

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 og de love, der ligger bag dets fakta, med datoen for kontrollen.