Back to blog
PrimentraPrimentra
·June 10, 2026·9 min read

Employee master data: the domain everyone assumes HR already handles

Home/Blog/Employee master data: the domain everyone assumes HR already handles
ONE PERSON, FOUR DOWNSTREAM COPIESHRISJ. Meyerstatus: LEFTterminated fridayActive DirectoryACTIVEERP approvalsACTIVEPayrollENDEDProject toolACTIVEterminated in HR. still approving invoices in the ERP.

Ask who owns employee master data and you get the fastest answer in the building: HR, obviously. They have a system for it. Of all the master data domains, this is the only one everyone assumes is already handled. Customer data has no natural home, supplier data gets fought over by procurement and finance, but employees? There is an entire department for that.

That assumption is exactly why employee data breaks in such a particular way. The HR system is real, and usually well maintained. It is just the system of record for a different thing than what the rest of your systems need.

The HRIS owns the employment record, not the employee record

What HR actually governs is the employment relationship: the contract, the salary, the leave balance, the performance file. Sensitive data, access-restricted, and of no use to anyone outside HR. The rest of the company needs a much thinner record. The ERP needs to know who approves what and which cost center to charge. The identity platform needs a job role and an active flag. The BI team needs headcount by department. Every one of those is a question about the person, not about the employment contract.

In system-of-record terms: the HRIS is the record for employment facts, and nobody disputes that. But the shared slice, the part every other system consumes, typically has no record at all. It has copies.

stays in HR

The employment record

  • Contract and salary
  • Leave balances
  • Performance reviews
  • Benefits and absence

Sensitive, access-restricted, and nobody else needs it.

everyone needs it

The shared slice

  • Employee ID and name
  • Department and cost center
  • Manager
  • Job role and active status

Referenced by the ERP, the identity platform, the project tool, and every report with headcount in it.

Where it actually breaks

Four failures account for most of the damage I have seen in this domain. Each one looks like a one-off when it happens. None of them are.

The leaver who kept approving

An employee is terminated in HR on a Friday. The ERP approval matrix does not read the HRIS, so the account sits there with full approval rights. Three weeks later the person has approved a stack of invoices they should never have seen. The auditor finds it before you do.

The contractor who does not exist

A contractor is not on payroll, so she never enters the HRIS. The project tool creates her as C-MEYER, the identity platform as jmeyer2, the ERP as a vendor contact. One person, three identities, and no way to answer who has access to what.

The move that never propagated

An internal transfer gets recorded in HR: new department, new cost center. Nobody tells the systems that allocate license costs and project hours. Finance books another quarter of this person against the old cost center and discovers it at close.

The org chart with two truths

HR maintains the line-management hierarchy. Finance maintains the cost center rollup. Both get called the org chart, they disagree about forty people, and every report picks one of them without saying which.

Notice that none of these are HR's fault. The HRIS did its job every time. The handoff to everything downstream was never anyone's job, and a process that is nobody's job runs on email and luck.

Why nobody centralizes it

The honest reason is privacy. Employee data feels radioactive, so the instinct is to keep all of it locked inside HR and replicate nothing. The instinct is reasonable. The conclusion is wrong, because the slice downstream systems need is the least sensitive part of the record: a name, a department, a manager, a status flag. Nobody's salary needs to leave the HRIS for the ERP to know that an approver left the company.

GDPR, the usual reason for not doing this, argues for governing the slice deliberately. Data minimization means each system should hold only what it needs, and right now the alternative to a governed thin record is not zero copies. It is an uncontrolled copy in every system, each with its own idea of what is current, none of them auditable. A privacy officer will take one governed, minimal, distributed record over that every single time.

The domain every other domain leans on

There is a second reason employee data deserves more attention than it gets, and it sits inside your MDM program itself. Every other domain references people. Supplier records carry an account manager. Cost centers have owners. Every entity in a governed setup has a data steward and an approver, and all of those are employee references.

When employee status goes stale, ownership across every other domain goes stale with it, silently. A supplier record whose responsible buyer left in March still shows an owner. The field is filled. The governance it represents is gone. That is how a data governance program dies without anyone deciding to kill it.

What to actually govern

The good news is that this is one of the smallest models you will ever build. One entity, a dozen attributes, a couple of reference lists. Concretely:

1

One identifier scheme for everyone

Employees and externals get IDs from the same sequence. Not the AD login, not the payroll number. A neutral key that survives name changes and rehires.

2

The thin slice, nothing more

Name, worker type, department, cost center, manager, job role, status. If an attribute is sensitive enough to make legal nervous, it does not belong here. It belongs in the HRIS.

3

Status with effective dates

Joiner, mover, leaver. The leaver event is the one that matters most: it has to reach downstream systems the same day, because every day of lag is a day of orphaned access and misrouted approvals.

4

The HRIS feeds it, the MDM governs it

Payroll employees flow in from the HR system. Externals get created directly in the MDM under the same rules, including an approval step before they go active.

5

Downstream reads, never writes

The ERP, the identity platform, and reporting consume the governed record. Corrections go to the source, not to the copy.

Departments and cost centers are their own entities, which the employee record references. If you have already governed your cost center structure, the employee domain plugs straight into it. Choosing the identifier deserves more thought than it usually gets; I wrote about why that choice is hard to reverse separately.

Set the cost of governing a dozen attributes against one misbooked quarter or one leaver with live approval rights, and this might be the cheapest domain in the whole multi-domain lineup. It is certainly the most ignored.

Common questions

What is employee master data?

The slice of person data that systems outside HR need to function: a stable ID, name, department, cost center, manager, job role, and active status. It is distinct from the employment record (contract, salary, leave), which stays in the HRIS. Approvals, access control, cost allocation, and headcount reporting all run on this slice.

Is the HR system not already the master?

For employment facts, yes. For the shared slice, no. The HRIS rarely distributes org assignment and status to the systems that need them, and it usually does not contain external workers at all. The HRIS feed is one input to a governed employee record, not the record itself.

What about contractors and externals?

They are the biggest gap. Because they are not on payroll, they never enter the HRIS, and each downstream system invents its own identity for them. Give externals an ID from the same scheme as employees and govern them in the same entity, distinguished by a worker type attribute.

Does GDPR allow centralizing employee data?

GDPR favors a deliberately thin, governed slice over the current default of uncontrolled copies everywhere. Distribute only what downstream systems need: ID, name, org assignment, manager, status. Salary, health, and performance data stay in the HRIS with its narrower access controls.

Govern the slice everyone shares

In Primentra, the employee record is one entity with domain attributes pointing at your department and cost center entities, an approval step before any change goes live, and a full audit trail of who changed what. Downstream systems read it through integration views or the REST API. It runs on SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial includes everything.

Start free trial →Try the demo →

More from the blog

Location master data: one warehouse, four system codes8 min readThe master data lifecycle, and the seams where data quietly goes bad9 min readThe chart of accounts is master data, and finance is running it from a spreadsheet9 min read

Ready to migrate from Microsoft MDS?

Join the waitlist and be the first to try Primentra. All features included.

Download Free TrialTry DemoCompare MDM tools
Employee master data: the domain everyone assumes HR already handles | Primentra