Reference data management: the part of your MDM strategy that breaks first

The quarterly report breaks. Not because the customer records are wrong, not because the supplier data is outdated. Because "Netherlands" is stored as "NL" in the ERP, "Netherlands" in the CRM, and "The Netherlands" in the BI staging area, and no tool can join on all three.

The underlying master data is fine. The reference data — the country code list that every entity references — is a mess. And in most organizations, nobody owns it.

What reference data actually is

Reference data is not master data. It is the controlled vocabulary that master data references. Country codes. Currency codes. Units of measure. GL account categories. Product status values. Department codes. Tax class codes. The lookup lists and classification hierarchies that your customer, product, and supplier records point to.

If you have worked with Microsoft MDS, you know these as domain-based attributes. A product record references a "ProductStatus" entity. A customer record references a "Country" entity. Those referenced entities — ProductStatus, Country, UnitOfMeasure — are reference data. Most MDS installations have dozens of them.

Why it is not the same as master data

Master data has a lifecycle. Customers get created, updated, merged, eventually deactivated. Products launch, get revised, get discontinued. Each record has a story you can follow through an audit trail. Reference data does not work that way, and treating it like a small version of master data is where most governance plans go wrong. The full breakdown of the two problems is here — this section covers the short version.

Retire a product status value that 3,000 products still reference and everything that reads those products downstream — your ERP, your BI tool, your API consumers — needs to handle the change. Add a new unit of measure that only one system knows about and imports start failing with validation errors everywhere else. That asymmetry — rare changes, wide blast radius — is the whole reason reference data needs its own rules.

This is why reference data governance needs to be stricter, not looser, than master data governance. Fewer people authorized to modify values. Every change — including adding a new code — goes through explicit approval. Retired values blocked from assignment to new records. A longer walkthrough of what counts as reference data, with more examples, is here if the list above was not enough.

The MDS migration trap

Organizations migrating off MDS almost always make the same mistake. They plan the migration around their core entities. Products first. Then customers. Then suppliers. Reference data gets written onto a sticky note: "migrate lookup tables later."

Later arrives on day two of the first import job. You try to load 10,000 product records and the import fails on 8,400 of them because the "Unit" field references "PCS" — which exists in MDS — but the new MDM tool only has "Pieces" and "Each" in its Units entity. Nobody migrated the unit of measure list first. Three hours of debugging later, someone realizes the fix is fifteen minutes of data work that should have happened before any products were touched.

Reference data should be migrated and validated before domain entities. Not after. Inverting this order multiplies the cleanup work.

The spreadsheet is not a governance strategy

When organizations do not put reference data into an MDM tool, it lands somewhere else. Usually a shared spreadsheet, or several competing ones. Finance has a GL account category spreadsheet. Product management has a category hierarchy Excel file. IT has a status code sheet from three years ago.

These diverge. Someone adds a new product category and updates their downstream system without telling anyone else. Six months later the MDM tool and the ERP disagree on what categories exist. Import jobs fail. BI reports show gaps. Analysts spend two days tracing the problem back to a row added in a spreadsheet that has no version history, no change notification, and no owner.

I have seen organizations with four separate "unit of measure" spreadsheets, each maintained by a different team, each treated as the authoritative list by a different system. All four were slightly different. None of them matched what was in the MDS installation. The migration planning meeting where this came to light was not a pleasant one.

What proper governance looks like

Reference data in an MDM tool is modeled the same way as any other entity — it has records, it has attributes, it has permissions and workflows. The governance model is what differs.

In Primentra, there is no separate reference data module. Every entity, including a reference entity, has a Requires approval toggle. Turn it on for Country or Status and assign the approvers: only users whose role carries the Approver flag, and who are named on that specific entity's approver list, can decide on a change. A steward can still propose a new code, but nothing commits until an assigned approver signs off, and the decision sits in the audit log afterward. The same mechanism gates changes to Products and Customers — reference data just gets a shorter approver list, and usually no self-approval.

How the reference list itself gets built

Primentra has no separate object type for reference data. A Country list, a Status list, a unit-of-measure list — each is an entity, built the same way as Customer or Product. What turns a plain entity into reference data is how other entities point at it.

Set an attribute's type to Domain and pick a target entity, and that field becomes a dropdown of records from the target — a Product's Status field pointing at a Status entity, a Customer's Country field pointing at a Country entity. In the grid, the value always reads as {Code} Name, for example {NL} Netherlands, and import matches on Code, Name, or the combined form. A user picks from a controlled list instead of typing a free-text value, so a reference can never point at something that doesn't exist.

Chain domain attributes and a hierarchy falls out for free. A Costcenter entity with a domain attribute to Area, and Area with one to Zone, gives you the chain Costcenter → Area → Zone — read straight from the attributes and drawn under the model automatically, with nothing separate to configure. Rename an entity or an attribute later and every dropdown and hierarchy keeps working, because the reference is stored as an internal ID, not a name.

The part that matters most for reference data specifically: an entity can be marked Shared across models. Country, Currency, and status codes usually belong to the whole organization, not to one model, so instead of rebuilding the list in every model that needs it, you build it once and share it. The data stays in its original model — sharing exposes it as a lookup target, it does not copy it — and permissions still apply. Microsoft MDS has no equivalent for this: a domain-based attribute there can only point within its own model, which is why MDS installations tend to accumulate near-duplicate Country or Currency entities, one per model.

Keeping it synchronized across systems

The country-code mess from the opening example — NL in the ERP, Netherlands in the CRM, The Netherlands in BI staging — is a synchronization problem as much as a governance one. Governing the list inside the MDM tool does not help if five other systems never read from it.

Primentra exposes every entity, including reference entities, as a real SQL view — a flat view of the entity's own columns, or a hierarchy view that carries a parent entity's columns alongside it. Any system that can query SQL Server — an ETL job, a BI tool, a reporting service — reads the same Code and the same ID column that Primentra itself resolves domain values against, so a join on the country code returns the same rows everywhere. The REST API and staging tables expose the same values for systems that integrate over HTTP or a load process instead of a live SQL connection.

Views drift when the underlying entity changes and nothing redeploys the view. Primentra compares the columns it last deployed against the entity's current attributes and flags the difference — a new attribute, a renamed one, a removed one — instead of letting downstream systems quietly disagree with the source. An administrator sees the warning and syncs it in one click. That is the piece a shared spreadsheet can never do: nobody gets an alert when a spreadsheet drifts from the systems reading it.

Where to start

Pick the domain causing the most pain and identify which reference entities it depends on. If it is the product domain, that is usually four things: product categories, unit of measure, product status, and tax class. Get those four entities into the MDM tool first. Define the authorized values. Assign an owner for each. Enable approval workflows.

Then import the product records. You will have far fewer validation failures and far less post-import cleanup because the controlled vocabulary your products reference already exists and is already governed.

Reference data is not glamorous. Nobody pitches it to the CFO. But it is load-bearing. Get it wrong and every domain that references it is fragile. Get it right before you import anything else and the rest of the migration becomes noticeably less painful.

Common questions