Master data management should establish who may define and change a shared business fact, how other systems identify it, and how disagreements are resolved. A central record is useful only when those decisions are explicit. Copying competing values into a new database can centralize disagreement without resolving it.
For a data and integration leader connecting sales, billing, and service applications, the practical decision is where authority belongs for each customer-related fact. The answer need not be one application for the entire customer. Legal identity, commercial relationships, billing arrangements, and service locations can have different owners and lifecycles.
Begin with the decisions that fail because systems disagree. Examples include a service entitlement attached to the wrong account, a customer statement sent under an obsolete name, or a consolidated report treating related entities as duplicates. Those failures reveal which identity and ownership rules are needed first.
“Customer” can mean a legal party, a sales relationship, a billing account, an operating location, or an individual contact. These objects can be related without being identical. A company group may contain several legal entities, each with several billing accounts and service locations.
Model those distinctions explicitly enough for the important workflows. The organization does not need an exhaustive ontology before making progress, but it must avoid using one identifier to stand for incompatible concepts. A sales account representing an entire group should not automatically become the legal counterparty for every invoice.
For each object, define identity, relevant relationships, lifecycle states, and permitted changes. Record how local identifiers map to the shared identity. Retain source identifiers so a disputed record can be traced back to its origin rather than becoming an unexplained row in the master-data platform.
Separate an identity correction from a business change. Correcting a misspelled organization name differs from recording a new legal name. Linking two confirmed representations of the same party differs from recording that one company acquired another. Those distinctions affect history and downstream interpretation.
A working ownership matrix should name the fact, authoritative source, business owner, steward, permitted writers, validation evidence, and conflict route. The business owner decides meaning and policy. A steward manages quality and exceptions. The technical custodian operates the system. One person may hold several roles in a small organization, but the responsibilities should remain distinguishable.
Authority can be field- or relationship-specific. The finance-controlled process may own a verified billing-party identifier, while service operations owns an installation location and sales owns a relationship classification. A shared record can present these facts together while preserving their different origins and approval requirements.
Avoid a universal “latest update wins” rule. A recent value entered by an unauthorized source should not displace a verified value merely because its timestamp is later. A legitimate update from an authoritative source may still need review if it conflicts with a business lifecycle rule or has a future effective date.
Specify what consumers may change. A service application might propose a correction to the legal name rather than overwriting the authoritative value. The proposal needs a destination, owner, and visible status so users do not resort to creating another local record to escape an unresolved issue.
Consider a hypothetical group with two companies, Harbor Trading Ltd and Harbor Services Ltd. They share a trading brand, office address, and central telephone number. A sales application stores one group-level account called Harbor. Billing maintains separate legal-party records for the two companies. Service maintains several installation locations.
A matching routine flags the records because their names and contact details are similar. Merging all of them into one “golden customer” would erase a distinction that billing and service need. The correct model may be one group relationship linked to two legal parties and their relevant accounts and locations, subject to verified evidence.
Now suppose the migration contains two hundred source records and flags thirty candidate duplicate pairs. After review in this teaching example, twenty-two pairs are confirmed as duplicate representations, while eight are legitimate related entities or accounts. The thirty flags are not thirty proven duplicates, and a similarity score is not automatically a calibrated probability of identity.
For each confirmed duplicate, the team preserves the source identifiers as aliases to the approved shared identity and records the evidence and decision. For the eight legitimate relationships, it records the appropriate relationship instead of merging. Existing transactions retain the identifiers and legal context necessary to interpret their history under the approved design.
If a merge is later found wrong, the team needs a controlled split procedure. It must identify affected relationships and downstream records, restore the correct identities, and reconcile consumers. A simple “undo” button in the master record may not reverse changes already propagated to other applications.
All names and quantities in this example are hypothetical. The lesson is operational: matching proposes identity relationships; accountable review and rules determine which relationships are valid.
A shared fact should carry enough context to explain where it came from, who approved a consequential change, and when it was effective. Provenance is the record of origin and derivation that supports that explanation. It is especially useful when two sources disagree or a consumer questions a value.
W3C’s PROV-O recommendation provides a model for representing provenance through entities, activities, and agents. An organization need not adopt that ontology to apply the underlying discipline, and the model does not decide which business source is authoritative. W3C PROV-O, Starting Point Terms
Distinguish business-effective time from the time the system learned about the change. A location change effective next month should not necessarily replace the current shipping location today. A correction received late may affect historical interpretation. The exact history model should follow the workflows that depend on it.
Version mappings and survivorship rules. A survivorship rule determines which value is retained when several candidates represent the same fact. If the rule changes, the team should be able to explain which records were affected and whether downstream views must be rebuilt. Treat the rule as controlled business logic rather than a hidden configuration choice.
Consumers need a stable way to obtain identities, relevant attributes, relationships, and changes. The contract should describe versioning, effective dates, deletion or deactivation, merge and split events, and how to resolve an unfamiliar identifier.
Use persistent identifiers where appropriate and avoid embedding mutable business meaning inside them. A code derived from a region or company name can become awkward when that attribute changes. A stable identifier still requires governance: uniqueness does not establish that two records refer to the same real-world object.
W3C’s Data on the Web Best Practices addresses provenance, version information, and persistent identifiers for published data. These practices are a useful design reference for shared enterprise data, while the internal authority model remains an organizational decision. W3C Data on the Web Best Practices, Sections 8.4, 8.6 and 8.7
Limit each consumer to the information it needs and is permitted to use. A common identity service does not justify replicating every attribute everywhere. Access, retention, and deletion handling should reflect the information’s sensitivity and applicable obligations, with appropriate specialist input.
Avoid update loops. If the master publishes a corrected name to a local application, that application should not treat the received value as a new independent authoritative edit and publish it back repeatedly. Preserve origin and version information and define which changes can create new proposals.
Data stewardship needs capacity, service expectations, and escalation. A queue of unresolved matches or proposed corrections can become a business bottleneck if no one owns the decision. Route the issue to the person who can verify the relevant fact, not merely the team that operates the database.
Prioritize by consequence. An identity conflict blocking a time-sensitive service action may deserve different treatment from a descriptive inconsistency in an analytical view. The prioritization rule should be transparent and avoid silently resolving difficult cases by choosing a convenient source.
Measure recurrence and downstream effect. A falling duplicate count is useful only if records were merged correctly. Track confirmed false merges, unresolved identity conflicts, consumer reconciliation differences, and repeated causes of poor capture. These measures reveal whether the process is improving business use rather than merely making the central table look cleaner.
Use feedback from consumers to repair source processes. If staff repeatedly create duplicate accounts because they cannot find an existing one, better search and capture guidance may matter more than a more aggressive matching algorithm.
A comprehensive master-data program can become too broad to deliver. Choose one object and a small set of consumers where disagreement has a concrete consequence. Define its relationships, authority matrix, matching evidence, change contract, and correction procedure.
Pilot both a merge and a split, a future-effective change, a source conflict, and a consumer that is temporarily unavailable. Verify that the resulting identities and relationships remain explainable after propagation. The central record is only one part of that test.
Master data management succeeds when connected systems can rely on shared facts without surrendering legitimate local meaning. The next useful step is to settle who owns one consequential fact, how that fact is identified, and how an incorrect decision will be corrected across every dependent system.
