Master Data Management in Salesforce: MDM Styles, Golden Records and Data Governance

Hey friends,

Master data management (MDM) in Salesforce means deciding which system owns each piece of customer data, and how conflicting versions get reconciled into one trusted record. You pick an implementation style (registry, consolidation, coexistence or centralized), define survivorship rules for the winning values, and add governance so the data stays classified, owned and traceable.

MDM is only 5% of the Salesforce Certified Platform Data Architect exam and governance is 10%, which makes this one of the cheapest places to pick up points. Here's how I'd explain it.

What is master data, and what is a golden record?

Master data is the core business data that many systems share and that changes slowly: customers, products, suppliers, locations. A golden record (the exam also says "system of truth") is the single best version of one of those entities, built from the fragments held in your different systems.

Say a customer is "Jen Smith" in the CRM, "Jennifer Smith" in billing and "J. Smith" in the support tool, each with a different email address. The golden record is the one customer row that has the right name, the right email and links back to all three source records.

What are the MDM implementation styles?

The exam objective lists "MDM implementation styles", and the names come from the MDM industry. They differ in where the master record lives and which way changes flow.

A quick way to remember them is by how much control the hub has: registry only links, consolidation copies and cleans, coexistence cleans and writes back, centralized owns everything. For the integration side of syncing, see my Salesforce integration patterns post.

How do survivorship rules pick the winning value?

When two source records disagree on an attribute, a survivorship rule decides which value wins. The exam guide calls this "criteria and methodology for picking the winning attributes". Common criteria:

• Source trust. Billing wins for billing address, the CRM wins for job title.
• Recency. The most recently updated value wins.
• Completeness. A populated value beats a blank one.
• Frequency. The value that appears in the most systems wins.

Matching adds thresholds and weights. Each field that you compare (name, email, phone) gets a weight, the weighted score is compared with a threshold, and records above it are treated as the same customer. Records in a gray zone between a high threshold and a low one go to a human data steward for review.

How do I build a golden record in a single Salesforce org?

With Salesforce as the hub, you use three standard tools together. Duplicate and matching rules stop new duplicates and flag existing ones, which I cover in Salesforce duplicate rules. Merge combines the duplicates, and an external ID field on each record keeps the source system's key, which preserves traceability back to where the data came from.

One limit worth knowing: a merge combines up to three records of the same type into one, the same limit as the user interface, and to merge more you do a successive merge. External ID fields can't be used with merge(). Both facts are in the SOAP API merge() reference.

Does Data Cloud create a golden record?

No, and this is a favorite trap. Salesforce's architects describe Data Cloud's Unified Profile as a key ring, not a golden record: it links the records from your systems of record without picking the best value for each attribute. It doesn't master or overwrite your data, and the Unified Profile ID isn't a permanent key, because the profile changes as identity resolution runs again. The full explanation is in the Rethinking the Golden Record post on the Salesforce Architects blog.

In MDM terms, that's close to the registry style. If you need a mastered golden record with winning values, you do that in your MDM tool or in a hub org, and feed Data Cloud with it. I wrote more about the product in my Data Cloud post.

How do I handle several Salesforce orgs or systems?

The exam objective is to represent a single view of the customer across multiple systems of interaction, and to consolidate or leverage data from multiple Salesforce instances. The tools are the same as above, in a different order of preference:

• Leave data where it is and link it. Registry style, a cross-reference table, or data virtualization with external objects when users only need to read it.
• Copy into one org. Consolidation style, when one org becomes the hub.
• Keep both and sync. Coexistence, with a clear owner for each field to avoid edit loops.

What is data governance in Salesforce?

Governance is the set of policies, owners and processes that keep data accurate, secure and compliant. The exam splits it into two skills: designing a data model that supports privacy regulations like the General Data Protection Regulation (GDPR), including how you identify, classify and protect personal and sensitive information, and designing an enterprise governance program.

Salesforce's built-in tool for classification is data classification metadata, documented in Data Classification Metadata Fields. It adds four properties to each field:

These are labels for your governance process. Salesforce Help states that changing Field Usage doesn't hide or expose a field, so they describe data and don't enforce access. Field-level security, sharing and encryption do the enforcing. You can report on the values and reach them through the API and Apex.

A governance program on top of that usually has data owners and stewards, a business glossary, quality rules, and an audit trail for changes. For the audit side, see Field Audit Trail vs Field History.

How does MDM show up on the exam?

Expect short scenarios: pick the style for a customer who can't move data, choose the winning-attribute method, say what Data Cloud does and doesn't do, or pick the right classification field. My practice questions include MDM and governance items, and the study plan shows where they fit in four weeks.

What do people get wrong about MDM?

• Calling Data Cloud's Unified Profile a golden record.
• Choosing coexistence when only one system ever edits the data, which is more complexity than you need.
• Skipping source IDs, which breaks traceability.
• Treating Data Sensitivity Level as a security control.
• Merging by hand at scale. The limit is three records per merge.

Quick backstory. I loved Focus on Force and used it on my way to 17 Salesforce certifications. At first I read the study guide cover to cover, then took the tests. What I eventually noticed: I learned way faster when I skipped ahead and took practice tests rapid-fire, reading the explanation for every miss. So I built Cert Lab around fast testing, with up-to-date doc links in every explanation. It's designed to test you to success.

FAQ

What are the four MDM implementation styles?

Registry, consolidation, coexistence and centralized (also called transaction).

What is a golden record?

The single best version of a customer, product or other entity, built from the records held in several systems.

How many records can I merge at once in Salesforce?

Up to three records of the same type per merge request. To merge more, do successive merges.

Is Data Cloud's Unified Profile a golden record?

No. It links records like a key ring, and doesn't pick winning values.

What does Data Sensitivity Level do?

It labels how sensitive a field is. It doesn't enforce access by itself.

Where should you go next?

• Salesforce data migration for loading the consolidated data.
• Salesforce large data volumes for scale.
• Standard object data model for the objects involved.
• Platform Data Architect study plan for the full exam.

Nick Frates, a senior Salesforce developer with 17 certifications, built the Platform Data Architect Cert Lab at nickfrates.com: rapid-fire practice questions for every exam section, each answer explained.

Hope this helps!

Best,

Nick