Skip to content
SteveTechArcSteveTechArc Courses

Study guide

Also in 28 languages

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 · 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.
Image generated with AI

Study guide for chapter 5 of the Data Architect course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries the exam’s Data Governance section (10%) and parts of Data Modeling (metadata) and Salesforce Data Management (consistency). It’s also where privacy law meets the data model. This is architecture, not legal advice: Legal decides what applies, and the architect makes it enforceable. Platform numbers change, so check the current ones before you rely on them.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

GOV-2: designing a governance program

  • I know record owner (a platform mechanism for access) isn’t the data owner (accountable for the data as a business asset), and that each field can record a Data Owner. (Record Owner Isn’t Data Owner)
  • I can tell the data owner (sets policy), the data steward (keeps it working) and the custodian (runs the system) apart. (Owner, Steward, Custodian)
  • Test knowledge: I know the three ways to run a governance program, centralized, federated (decentralized) and hybrid, and what each means for who sets policy and where the shared definitions live. (How the Program Runs)
  • I can use a RACI to answer where data is created, edited and referenced. (Make the RACI Earn Its Place)
  • I can name an enforcement point for a governance policy (permissions, validation, integration-only fields, field history), not just training. (Governance Has to Become Mechanical)
  • I know quality signals worth measuring are the ones someone will act on. (Measure What Someone Will Act On)

SDM-2 and MDM-4: keeping bad data out

DM-3: business and technical metadata

  • Test knowledge: I know business metadata (meaning, definitions, owner, rules, sensitivity) from technical metadata (objects, fields, types, API names, schemas, mappings, lineage). (Two Kinds of Metadata)
  • I know the difference between a business dictionary (what it means), lineage (where it came from) and classification (how it must be treated). (Know Your Data)
  • I know Salesforce’s classification fields: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, on standard and custom fields. (Classification Answers a Different Question)
  • I know to classify the sensitive fields, not every field, and that classification without enforcement is decoration. (Classification Without Enforcement Is Decoration)

GOV-1: personal and sensitive data

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • A policy without an enforcement point is mostly a wish.
  • Owners set policy; architects enforce it. Don’t invent the policy, and don’t play lawyer.
  • Governance is never finished. It ebbs and flows; design the feedback.
  • Don’t rely on good behavior. Build the control: people, integrations and agents all make mistakes.
  • Govern enough, not everything.
  • Prevent the expensive errors first. A duplicate with two years of history is a big problem.
  • Distinguish what people read from what machines decide on.
  • Document broadly; classify deliberately.
  • The cheapest sensitive data to govern is the data you never copied.
  • Consent is data, and permission to use data has to be representable as data.
  • Control where personal data goes first, because deletion is rare and hard.
  • Compliance isn’t a product.
  • Capture → Classify → Protect → Use → Retain → Delete → Audit.
  • Capture the evidence before anyone asks for it.

Words to Know

Section titled “Words to Know”
TermIn one line
Data governanceThe policies for data, and the architecture that makes them true
Data ownerThe person or function accountable for a kind of data
Data stewardThe person who keeps the data healthy day to day
CustodianThe team that operates the systems holding the data
RACIResponsible, Accountable, Consulted, Informed
Provisional recordA record created before the authoritative system has accepted it
Business dictionaryAgreed definitions of the business’s important terms
LineageWhere a value came from and what happened to it on the way
Data classificationLabeling data by sensitivity and compliance category so it gets the right controls
TaxonomyThe set of labels an organization uses to classify data
Personal dataInformation that identifies a person, or can be linked back to one
PseudonymizationReplacing identifiers while a way back still exists; still personal data
AnonymizationRemoving the reasonable ability to identify the person
Consent data modelSalesforce’s objects for consent by person, channel, contact point and purpose
Right to be forgottenA person’s right, where the law gives it, to have their personal data erased
Hybrid golden recordOne record with the master system’s fields and Salesforce’s own fields, each with one source
Business / technical metadataWhat the data means and who owns it / how it’s built and moves
Field Audit TrailLonger field history: up to 200 fields per object, kept until deleted
Event MonitoringLogs of logins, exports, API calls and views, kept for a limited time
SIEMA security repository where event logs are kept and analyzed

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. The policy says only Finance may change a customer's legal name. The team plans to cover it in training. What's missing?

An enforcement point. Training isn’t a control: use field-level access, a field only the integration writes, a validation rule, or a controlled process. Owners set the policy; the architect makes it mechanically true. Reread Governance Has to Become Mechanical.

2. Customers are mastered in the ERP. Sales reps need to start selling to new prospects right away. How do you let them, without two systems creating the master record?

Let reps create the account as a provisional record type, then convert it through a controlled process: Finance approves, or the integration submits it to the ERP, which matches or creates the customer and sends back the authoritative ID. Reread The Middle Path.

3. A new required field fills with "N/A" and "999999". What happened, and what would you do instead?

Users were forced to answer before they knew. Require it later in the process, let another system supply it, use a provisional state, or allow an explicit Unknown when that’s a real answer. Reread Don’t Let Required Fields Create Fake Data.

4. The team replaced names with tokens and says the data is anonymized, so the deletion request is done. Is it?

Not if the tokens can be linked back to the person: that’s pseudonymization, and the data is still personal. Say exactly what the system does, where the mapping lives, and let Legal decide whether it satisfies the requirement. Reread Anonymized, Pseudonymized, Encrypted, Masked.

5. A Recipient agrees to delivery texts but not marketing. How should the model hold that?

With the consent data model, not one checkbox: the person, the channel (SMS), the specific number, and the data use purpose (delivery notifications, not marketing). And decide which system is authoritative for consent so a withdrawal reaches every system that acts on it. Reread Use the Model Salesforce Already Built.

6. Compliance needs to filter reports on an encrypted Social Security field. The field uses the default encryption scheme. What's the issue?

Probabilistic encryption doesn’t allow filtering in SOQL WHERE clauses or data-management filters. Deterministic encryption allows filtering at a small cost in strength. Encryption is a design decision with trade-offs, not a checkbox at the end. Reread Encryption Is a Control, Not Compliance.

7. Six months after an incident, someone asks who exported a set of records. Nobody set up Event Monitoring storage. What can you tell them?

Probably nothing: event logs are kept for a limited time (at most a year, even extended), so anything older is gone unless it was exported. Set up Event Monitoring and send the events to a SIEM before you need them. Reread Auditing and Monitoring Aren’t the Same.

8. A rep asks Salesforce to change a customer's legal name, which the ERP masters. In the same minutes someone changes it in the ERP. What should the design say?

That Salesforce was asking, not changing: the ERP masters the field. Decide the collision rule up front (the ERP wins, reject if the value changed, or a person resolves it) and whether related fields travel together. Reread Protect the Governed Record.

9. A person's erasure request arrives. The team plans to start mapping where their data lives. What's the problem?

The clock is already running: under GDPR, one month, extendable by two more for complex requests. The map of copies has to exist before the request arrives. Reread The Clock Is Running.

Explore

Section titled “Explore”