Datakvalitet och styrning

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)

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. — Bilden är skapad med AI

Studieguide för kapitel 5 i kursen Data Architect. Läs de sex modulerna först; 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 plugga in svar är ändå fel sätt att bli arkitekt.

Det här kapitlet bär provets avsnitt Data Governance (10 %) och delar av Data Modeling (metadata) och Salesforce Data Management (konsistens). Det är också här integritetslagstiftningen möter datamodellen. Det här är arkitektur, inte juridisk rådgivning: Juridik avgör vad som gäller, och arkitekten gör det möjligt att genomdriva. Plattformens siffror ändras, så kontrollera de aktuella innan du förlitar dig på dem.

Inför provet

Bocka av dem allt eftersom. Varje punkt länkar till där den lärs ut.

GOV-2: att designa ett styrningsprogram

Jag vet att postens ägare (en mekanism i plattformen för åtkomst) inte är dataägaren (som ansvarar för data som en affärstillgång), och att varje fält kan registrera en Data Owner. (Postens ägare är inte dataägaren)
Jag kan skilja på dataägaren (sätter policyn), dataförvaltaren (håller det igång) och förvararen (driver systemet). (Ägare, förvaltare, förvarare)
Provkunskap: Jag känner till de tre sätten att driva ett styrningsprogram, centraliserat, federerat (decentraliserat) och hybrid, och vad var och ett betyder för vem som sätter policyn och var de gemensamma definitionerna bor. (Hur programmet drivs)
Jag kan använda en RACI för att svara på var data skapas, redigeras och refereras. (Låt RACI:n förtjäna sin plats)
Jag kan namnge en punkt där en styrningspolicy genomdrivs (behörigheter, validering, fält som bara integrationen skriver, fälthistorik), inte bara utbildning. (Styrningen måste bli mekanisk)
Jag vet att de kvalitetssignaler som är värda att mäta är de som någon kommer att agera på. (Mät det som någon kommer att agera på)

SDM-2 och MDM-4: att hålla dåliga data ute

Jag kan avgöra om skapandet av konton ska vara öppet eller låst, och jag känner till vägen via en provisorisk posttyp för konton som hanteras som masterdata i ett ERP. (Öppet eller låst?, Mellanvägen)
Jag kan skydda styrda attribut (ett ERP-ID, ett juridiskt namn) och samtidigt låta Salesforce egna fält vara redigerbara: en hybrid golden record. Och jag vet att ett skrivskyddat fält på en sida med Dynamic Forms inte är genomdrivande; det är säkerhet på fältnivå eller en valideringsregel. (Skydda den styrda posten, En posttyp för varje flöde)
Jag vet att dubbelriktade flöden är svårast: om ERP:t är master för ett fält ber Salesforce om att få ändra det, och en kollision behöver en regel (ERP:t vinner, avvisa om värdet har ändrats, eller en människa löser det). (Skydda den styrda posten)
Jag vet att obligatoriska fält kan skapa falska data (N/A, 999999), och vilka alternativen är. (Låt inte obligatoriska fält skapa falska data)
Jag kan avgöra vad som händer med inkommande data som inte klarar kontrollerna: acceptera, avvisa eller sätta i karantän, och vem som äger undantaget. (Varje datagräns behöver ett kvalitetsbeslut)
Jag vet att referensdata också behöver metadata: definitioner, en ägare, en källa och mappningar mellan system. (Referensdata behöver också metadata)

DM-3: affärsmetadata och teknisk metadata

Provkunskap: Jag kan skilja på affärsmetadata (betydelse, definitioner, ägare, regler, känslighet) och teknisk metadata (objekt, fält, typer, API-namn, scheman, mappningar, härkomst). (Två typer av metadata)
Jag vet skillnaden mellan en affärsordlista (vad data betyder), härkomst (var de kom ifrån) och klassificering (hur de måste hanteras). (Känn dina data)
Jag känner till klassificeringsfälten i Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, på standardfält och anpassade fält. (Klassificering besvarar en annan fråga)
Jag vet att jag ska klassificera de känsliga fälten, inte alla fält, och att klassificering utan genomdrivande är dekoration. (Klassificering utan genomdrivande är dekoration)

GOV-1: personuppgifter och känsliga uppgifter

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 policy utan en punkt där den genomdrivs är mest en önskan.
Ägarna sätter policyn; arkitekterna genomdriver den. Hitta inte på policyn, och lek inte jurist.
Styrning blir aldrig klar. Den går i ebb och flod; designa återkopplingen.
Lita inte på gott uppförande. Bygg kontrollen: människor, integrationer och agenter gör alla misstag.
Styr tillräckligt, inte allt.
Förebygg de dyra felen först. En dubblett med två års historik är ett stort problem.
Skilj på det som människor läser och det som maskiner fattar beslut utifrån.
Dokumentera brett; klassificera medvetet.
De billigaste känsliga data att styra är de data du aldrig kopierade.
Samtycke är data, och tillåtelsen att använda data måste kunna representeras som data.
Kontrollera först vart personuppgifterna tar vägen, eftersom radering är ovanlig och svår.
Regelefterlevnad är ingen produkt.
Fånga → Klassificera → Skydda → Använda → Bevara → Radera → Granska.
Fånga bevisen innan någon ber om dem.

Ord att kunna

Term	På en rad
Datastyrning (data governance)	Policyerna för data, och arkitekturen som gör dem sanna
Dataägare	Den person eller funktion som ansvarar för en typ av data
Dataförvaltare (data steward)	Personen som håller data friska i det dagliga
Förvarare (custodian)	Teamet som driver systemen där data finns
RACI	Responsible, Accountable, Consulted, Informed (utför, ansvarar, rådfrågas, informeras)
Provisorisk post	En post som skapats innan det auktoritativa systemet har accepterat den
Affärsordlista	Överenskomna definitioner av verksamhetens viktiga begrepp
Härkomst (lineage)	Var ett värde kom ifrån och vad som hände med det på vägen
Dataklassificering	Att märka data efter känslighet och kategori för regelefterlevnad så att de får rätt kontroller
Taxonomi	Uppsättningen etiketter som en organisation använder för att klassificera data
Personuppgifter	Information som identifierar en person, eller kan kopplas tillbaka till en
Pseudonymisering	Att ersätta identifierare medan det fortfarande finns en väg tillbaka; fortfarande personuppgifter
Anonymisering	Att ta bort den rimliga möjligheten att identifiera personen
Samtyckesdatamodell	Salesforce objekt för samtycke per person, kanal, kontaktpunkt och ändamål
Rätten att bli bortglömd	En persons rätt, där lagen ger den, att få sina personuppgifter raderade
Hybrid golden record	En post med mastersystemets fält och Salesforce egna fält, var och en med en källa
Affärsmetadata / teknisk metadata	Vad data betyder och vem som äger dem / hur de är byggda och rör sig
Field Audit Trail	Längre fälthistorik: upp till 200 fält per objekt, sparas tills den raderas
Event Monitoring	Loggar över inloggningar, exporter, API-anrop och visningar, som sparas en begränsad tid
SIEM	Ett säkerhetslager där händelseloggar sparas och analyseras

Testa dig själv

Korta scenarier i kursens stil. Bestäm ditt svar innan du öppnar det.

1. Policyn säger att bara Ekonomi får ändra en kunds juridiska namn. Teamet planerar att ta upp det i utbildningen. Vad saknas?

En punkt där policyn genomdrivs. Utbildning är ingen kontroll: använd åtkomst på fältnivå, ett fält som bara integrationen skriver, en valideringsregel eller en kontrollerad process. Ägarna sätter policyn; arkitekten gör den mekaniskt sann. Läs om Styrningen måste bli mekanisk.

2. Kunderna hanteras som masterdata i ERP:t. Säljarna behöver kunna börja sälja till nya prospekt direkt. Hur låter du dem göra det, utan att två system skapar masterposten?

Låt säljarna skapa kontot som en provisorisk posttyp, och konvertera det sedan genom en kontrollerad process: Ekonomi godkänner, eller integrationen skickar det till ERP:t, som matchar eller skapar kunden och skickar tillbaka det auktoritativa ID:t. Läs om Mellanvägen.

3. Ett nytt obligatoriskt fält fylls med ”N/A” och ”999999”. Vad hände, och vad skulle du göra i stället?

Användarna tvingades svara innan de visste. Gör fältet obligatoriskt senare i processen, låt ett annat system leverera värdet, använd ett provisoriskt tillstånd, eller tillåt ett uttryckligt Okänt när det är ett verkligt svar. Läs om Låt inte obligatoriska fält skapa falska data.

4. Teamet har ersatt namn med token och säger att data är anonymiserade, så raderingsbegäran är klar. Är den det?

Inte om tokenen kan kopplas tillbaka till personen: det är pseudonymisering, och uppgifterna är fortfarande personuppgifter. Säg exakt vad systemet gör och var mappningen finns, och låt Juridik avgöra om det uppfyller kravet. Läs om Anonymiserat, pseudonymiserat, krypterat, maskerat.

5. En mottagare (Recipient) går med på sms om leveranser men inte på marknadsföring. Hur ska modellen hålla det?

Med samtyckesdatamodellen, inte en enda kryssruta: personen, kanalen (sms), det specifika numret och ändamålet för dataanvändningen (leveransaviseringar, inte marknadsföring). Och bestäm vilket system som är auktoritativt för samtycke så att en återkallelse når varje system som agerar på det. Läs om Använd modellen som Salesforce redan har byggt.

6. Compliance behöver filtrera rapporter på ett krypterat fält för amerikanskt personnummer (Social Security). Fältet använder standardschemat för kryptering. Vad är problemet?

Probabilistisk kryptering tillåter inte filtrering i SOQL-satser med WHERE eller i filter för datahantering. Deterministisk kryptering tillåter filtrering till priset av något lägre styrka. Kryptering är ett designbeslut med avvägningar, inte en kryssruta i slutet. Läs om Kryptering är en kontroll, inte regelefterlevnad.

7. Sex månader efter en incident frågar någon vem som exporterade en uppsättning poster. Ingen har satt upp lagring för Event Monitoring. Vad kan du säga?

Förmodligen ingenting: händelseloggar sparas en begränsad tid (högst ett år, även med förlängning), så allt äldre är borta om det inte exporterades. Sätt upp Event Monitoring och skicka händelserna till en SIEM innan du behöver dem. Läs om Granskning och övervakning är inte samma sak.

8. En säljare ber Salesforce att ändra en kunds juridiska namn, som ERP:t är master för. Under samma minuter ändrar någon det i ERP:t. Vad ska designen säga?

Att Salesforce bad om en ändring, inte ändrade: ERP:t är master för fältet. Bestäm kollisionsregeln i förväg (ERP:t vinner, avvisa om värdet har ändrats, eller en människa löser det) och om relaterade fält följer med tillsammans. Läs om Skydda den styrda posten.

9. En persons begäran om radering kommer in. Teamet planerar att börja kartlägga var personens uppgifter finns. Vad är problemet?

Klockan tickar redan: enligt GDPR en månad, som kan förlängas med ytterligare två för komplicerade begäranden. Kartan över kopiorna måste finnas innan begäran kommer. Läs om Klockan tickar.

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 och lagarna bakom dess fakta, med datum för kontrollen.