Skip to content
SteveTechArcSteveTechArc Courses

Data Quality and Governance

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)

Chapter 5 of Data Architect, Part 1: Becoming a Data Architect. Previous: Understanding Enterprise Data.

Say “data governance” and people picture meetings: committees, policies, a document nobody reads. I ask a different question every time: where is the policy enforced?

If the policy says only Finance may change the legal customer name, what stops anyone else? If it says crews see a Recipient’s address only for their own stops, only on the day, what makes that true? If it says keep this for seven years, what removes it after seven? A policy without an enforcement point is mostly a wish. My position is simple: owners set policy; architects enforce it. The data owner decides. The system the architect designs makes it mechanically true.

And don’t expect to finish. Governance is never finished. It runs in ebbs and flows, keeping out the worst of the bad data. It’s simple when Salesforce stands alone, and harder, and more necessary, when Salesforce is one node in the landscape we drew in chapter 4. That’s why that chapter came first: the landscape tells you how far governance has to reach.

A finance director explains the data policies while the architect pins what enforces each one: validation, sharing and retention

Image generated with AI.

The positions in this chapter

Section titled “The positions in this chapter”
  • Run the program the way the company works: centralized, federated or hybrid; the architect needs to know who signs off a policy.
  • Record owner isn’t data owner. The Owner field drives assignment and access; accountability for the data lives with the business.
  • Open or locked creation depends on the governance around the data. Open is fine for most small and mid-sized orgs; lock it down when accounts are mastered in or synced with an ERP; the middle path is a provisional record type with controlled conversion to the governed one.
  • If the ERP masters a field, you aren’t changing it, you’re asking to change it. The golden record is a hybrid: the ERP’s master fields come in, Salesforce’s own fields never go back, and bi-directional flows need a collision rule.
  • Classify the sensitive fields, not every field. Document broadly; classify deliberately; keep business and technical metadata both.
  • Teach the regulations. Many architects have never heard of the laws outside their own region, and these laws shape system design.
  • Use the out-of-the-box consent model wherever you can, rather than rebuilding it.
  • For the right to be forgotten, control where personal data goes first. Deletion is rare and hard; design so personal data lands in few places, then hunt down every copy: field history, archives, the analytics copies, search indexes and agent conversations, before the clock runs out.
  • Shield is the answer for key regulatory requirements like encryption at rest, with trade-offs you design for.
  • Field Audit Trail when regulated. Standard field history is the default.
  • Set up Event Monitoring before you need it, and stream the events into a repository such as Splunk. You don’t run into an issue and then find out you weren’t capturing them.

The governed data lifecycle

Section titled “The governed data lifecycle”
The governed data lifecycle The governed data lifecycle in seven stages, each with its question and example Salesforce mechanisms. Capture: is it good enough to let in? Validation rules, duplicate rules, required fields, a quality gate; module 2. Classify: how sensitive is it? The data classification fields for sensitivity, compliance and owner; module 3. Protect: who may see and change it? Sharing, permissions, field access, Shield encryption and sandbox masking; module 6. Use: is this use permitted? The consent model, data use purpose, and integration and agent access; module 5. Retain: how long do we keep it? Retention policies, archives, big objects; module 6. Delete: what happens at the end? Privacy Center, deletion jobs, de-identification; module 5. Audit: can we prove it? Field history, Field Audit Trail, and Event Monitoring sent to a SIEM; module 6. Underneath: tools support the policy; they don't define it. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.28.0", "built": "2026-10-15", "id": "DGM-DA-QG-61", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape/inventory 0.10.0", "theme": "stevetecharc 1.4.0"} STAGE THE QUESTION SALESFORCE MECHANISMS, FOR EXAMPLE TAUGHT IN 1 · Capture Is it good enough to let in? Validation rules, duplicate rules, required fields, a quality gate Module 2 2 · Classify How sensitive is it? Data classification fields: sensitivity, compliance, owner Module 3 3 · Protect Who may see and change it? Sharing, permissions, field access, Shield encryption, sandbox masking Module 6 4 · Use Is this use permitted? Consent model, data use purpose, integration and agent access Module 5 5 · Retain How long do we keep it? Retention policies, archives, big objects Module 6 6 · Delete What happens at the end? Privacy Center, deletion jobs, de-identification Module 5 7 · Audit Can we prove it? Field history, Field Audit Trail, Event Monitoring to a SIEM Module 6 Tools support the policy; they don't define it. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Seven questions across the data’s life. Tools support the policy; they don’t define it.

The path through this chapter

Section titled “The path through this chapter”

Six modules, each one standing on its own.

  1. Governance Is Designed Into the Org. Owners, stewards and custodians; centralized, federated or hybrid; record owner vs data owner; turning every policy into an enforcement point.
  2. Keeping Bad Data Out. Good enough as a business definition; open vs locked creation, the provisional record and a record type for each flow; the hybrid golden record and bi-directionals; a quality decision at every data boundary.
  3. Know Your Data: Dictionary, Lineage and Classification. Business and technical metadata; what it means, where it came from, how it must be treated, and why classification without enforcement is decoration.
  4. Privacy Laws Shape the Design. The laws to recognize, what they have in common (rights, transfers, breach notification, accountability), and the questions that outlive them; anonymized vs pseudonymized; compliance isn’t a product.
  5. Consent and the Right to Be Forgotten. Consent as data, the standard consent model, the clock on every request, and designing erasure before the first one arrives.
  6. Protect, Retain and Prove. Encryption’s trade-offs, sandboxes, retention, field history and Field Audit Trail, and Event Monitoring set up ahead of need.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

Section titled “What an architect decides here”
  • Who owns each important data domain, and what enforces each owner’s policy.
  • What bad data is kept out, and what’s caught, quarantined and fixed later.
  • Which fields are sensitive, and what that classification changes.
  • Where personal data goes, what it may be used for, and how it’s removed from every copy.
  • How long data and its history are kept, and what evidence exists to prove what happened.

This chapter is architecture guidance, not legal advice. Legal and compliance teams decide which laws apply and what they require; the architect turns those requirements into design.

Beyond the exam: governance has a new consumer, the agent. Classification decides what it may retrieve, consent decides what it may use the data for, and lineage and audit have to reach all the way to what it said and did. Each module ends with what AI changes for its part of the lifecycle.

Explore

Section titled “Explore”

Next: Master Data and Identity