A master data golden record is the governed representation of a business entity assembled from one or more source records. It is not necessarily the row from the most powerful application, and it is not proof that every source is wrong. A useful golden record states which entity the organization believes exists, which attributes are currently trusted, where each value came from, and which steward or rule resolved uncertainty.
ERP, CRM, and commerce systems view the same customer or product through different processes. ERP may control legal billing identity, CRM relationship ownership, and commerce descriptions and digital assets. Forcing one system to author every field damages fit. The design should assign authority by domain and attribute, match records with explainable evidence, apply survivorship rules, route ambiguity to stewards, and publish changes without creating update loops.
Define the entity and domain boundary
Begin with the business entity, grain, and lifecycle. A legal organization, selling account, shipping location, household, contact, product model, SKU, and trade item are related but not interchangeable. Define create, merge, split, inactivate, and reactivate semantics. State whether the golden record represents identity, a current operational view, or both. Ambiguous grain causes false matches and overloaded identifiers before algorithms run.
Choose stable identifiers. Internal master IDs connect contributing records; external standards can support exchange where the domain fits. GS1 standards provide globally recognized identification and data-sharing structures for products, locations, and other supply-chain entities. ISO 8000-115 specifies characteristics for quality identifiers in master-data exchange. Standards improve interoperability, but they do not decide whether two local records describe the same real-world entity.
| Data domain | Likely authority | Shared attributes | Stewardship risk |
|---|---|---|---|
| Customer legal identity | ERP or governed customer master | Legal name, tax ID, billing status | Subsidiaries merged as one account |
| Sales relationship | CRM | Account owner, segment, opportunity link | Relationship data overwrites legal truth |
| Commerce profile | Commerce or customer profile service | Display name, preferences, digital identity | Consent and identity conflated |
| Product commercial master | ERP or PIM by attribute | SKU, unit, tax, cost, status | One system treated as authority for all content |
| Product content | PIM or commerce | Title, description, media, channel taxonomy | Localization and approval provenance lost |
Assign authority at attribute level
Create a matrix for every material attribute: definition, format, authoritative system, allowed contributors, validation, freshness, sensitivity, and steward. Authority can depend on lifecycle. CRM may propose a customer, while ERP becomes authoritative for legal and payment fields after onboarding. A supplier may author product dimensions, while internal quality approval controls publishability. Encode transitions so latest timestamp does not overrule a more trustworthy process.
Separate source authority from consumption. CRM can continue using a local copy of ERP billing status, but it may not edit it. Commerce can enrich product content without becoming authority for base unit. Publish field provenance and freshness so users understand why values differ. A system-of-record label at whole-record level is too coarse for composite masters.
Normalize without erasing source evidence
Standardize case, whitespace, punctuation, addresses, phone formats, units, identifiers, and character encoding in derived comparison fields. Preserve the original value and transformation version. Normalize only with domain-aware rules: removing legal suffixes can aid candidate matching but should not alter the registered name; converting units requires precision and source unit; transliteration can create collisions and must not replace native script.
Validate required patterns, code lists, ranges, relationships, and effective dates at ingestion. Invalid data may still be useful as evidence and should enter a remediation queue rather than vanish. Distinguish missing, explicitly unknown, not applicable, and withheld values. Collapsing them to null makes survivorship and downstream obligations unreliable.
Generate and score match candidates transparently
Use deterministic rules for strong identifiers, then probabilistic or fuzzy comparisons for names, addresses, contact points, and descriptions. Block candidates into plausible groups to control cost. Weight evidence by stability and domain; a verified tax identifier should matter differently from a similar trading name. Record the rule version, features, score, and explanation for every proposed link. Microsoft Dataverse documentation illustrates rule-based match codes and warns that concurrent creation can still produce duplicates, reinforcing the need for periodic detection.
Define separate thresholds for auto-link, steward review, and no-link. Calibrate against labeled examples and inspect false merges and missed matches by region, language, entity type, and source. False merges can expose another customer's activity or combine financial positions, so their cost may exceed duplicate records. Never allow a model score alone to merge protected or high-risk entities without appropriate evidence and review.
Apply field-level survivorship rules
Survivorship selects a current golden value from contributing claims. Rules can prefer authoritative source, verified status, highest quality, most recent approved value, or a steward override. Recency should be bounded by source authority and effective time. An old verified legal name can outrank a new unverified lead form. Store all claims and the reason for selection rather than destructively copying winning values into one opaque row.
Make overrides explicit, scoped, and expiring where facts can change. A steward can pin a legal parent after investigation while allowing phone and address fields to continue automatic updates. Recompute affected golden records when rules change, but preview the population and downstream impact first. A survivorship release is a data migration and needs version, tests, reconciliation, rollback, and communication.
| Survivorship rule | Suitable use | Required guardrail | Failure mode |
|---|---|---|---|
| Authoritative source wins | Governed legal or financial attribute | Document lifecycle and fallback | Stale authority never challenged |
| Verified value wins | Email, phone, identifier, address | Define verifier and expiry | Verification status copied incorrectly |
| Most recent approved | Frequently changing operational attribute | Use event and effective time | Late batch overwrites newer truth |
| Quality score wins | Content completeness and formatting | Explain score and tie handling | Cosmetic completeness beats correctness |
| Steward override | Ambiguous or exceptional entity | Reason, scope, actor, review date | Permanent undocumented manual truth |
Design stewardship queues around decisions
Create queues for possible duplicate, conflicting authoritative claims, invalid identifier, missing required attribute, merge appeal, and suspected split. Prioritize by customer harm, financial exposure, downstream reach, confidence, and age. Give stewards side-by-side source evidence, provenance, differences, relationships, activity, and predicted impact. Do not ask them to choose between two rows without explaining the entity model and rule that created the case.
Measure decision turnaround, reversal rate, backlog age, false-merge incidents, rule precision, and recurrence by source. Sample auto-decisions for quality. Steward productivity is not simply cases closed; rushed merges can be more expensive than backlog. Route systemic source defects to owners so stewards do not repeatedly repair the same missing identifier.
Preserve provenance and effective history
For each golden attribute, retain source system, source record, original value, ingestion time, business effective time, normalization, validation, selected rule, and steward action. W3C PROV provides a model built around entities, activities, and agents that can inform interoperable provenance. The implementation need not use RDF, but it should answer what value was used, how it was derived, and who or what made the decision.
Use bitemporal concepts where historical truth matters: when the fact was effective and when the platform learned it. This supports backdated legal changes and audits. Merge should create identity links and history rather than delete contributors. Split must reassign claims and downstream references carefully. Preserve aliases or redirects so old master IDs resolve according to policy.
Publish without feedback loops
Emit versioned changes with master ID, changed attributes, provenance summary, effective time, and event identity. Consumers apply idempotently and respect field authority. Mark outbound updates so a source connector does not ingest its own echoed value as fresh evidence. Use source-specific record IDs and correlation to distinguish an acknowledgment from a new business edit.
Reconcile published versions to critical consumers. Define what happens when a target rejects a merge or cannot represent a hierarchy. Some systems may retain local views while mapping to the common master ID. A golden record should not become a synchronous dependency for every transaction; cache or replicate governed views according to freshness and outage requirements.
Key takeaways
- Define entity grain and lifecycle before matching records.
- Assign authority by attribute and process stage, not by application prestige.
- Preserve original claims, normalization, and rule provenance.
- Calibrate auto-link thresholds around the cost of false merges.
- Give stewards decision-specific evidence and route recurring defects upstream.
- Publish versioned, idempotent changes and prevent connector feedback loops.
Frequently asked questions
Must one system own the entire golden record?
No. Authority commonly varies by attribute and lifecycle. The golden record can assemble governed claims while operational systems retain responsibility for the processes that create them.
Why not let the latest value win?
A recent unverified or low-authority update can overwrite a validated fact, and batch arrival time may not equal business effective time. Recency needs authority, verification, and time semantics.
Can machine learning decide all duplicates?
It can rank candidates, but high-impact ambiguous cases need explainability, calibrated thresholds, monitoring, and human review. The organization remains accountable for merges and downstream effects.
Conclusion
Golden records become trustworthy through explicit authority and reversible evidence, not through a single perfect database. Clear entity models, standards-aware identifiers, explainable matching, field-level survivorship, supported stewards, provenance, and controlled publication let ERP, CRM, and commerce share identity without erasing their legitimate process roles.