CRM is not a master register — and it shouldn't try to be

The dangerous temptation

It happens in nearly every implementation project. Somewhere between kick-off and go-live, the question surfaces — usually from someone hoping to simplify the architecture: "Don't we already have all the customer data in the CRM? Couldn't we just use that as our master source?"

The answer is no — with nuances. In smaller organisations with few data consumers, a CRM can pragmatically serve as the closest thing to a master register. But the more systems that read from the register, and the more critical the decisions it supports, the weaker the CRM becomes as master. And the reason isn't technical weakness in the platform — it's a fundamental contradiction in what the two systems are designed to do.

The CRM's actual mission: openness at the expense of purity

A good CRM system — whether Microsoft Dynamics 365, Salesforce or any other — is built around one core idea: lower the threshold for data entry to zero.

A salesperson who meets a potential customer at an event should be able to create the contact on their phone between two sessions, with just a first name and a LinkedIn profile picture. A customer service representative should be able to log an inquiry even if the customer's name already exists three times in the system. The marketing team should be able to import a list from a trade show without half of it being rejected by validation rules.

This isn't sloppiness — it's architectural intent. The alternative is that the data never gets registered at all. Instead it ends up in an Excel file on someone's desktop, in an Outlook folder, or — worst case — only in the head of the employee who handled it. Data that isn't in the system doesn't exist as far as the organisation is concerned.

A CRM must therefore tolerate duplicates (the same customer registered slightly differently by different users), incomplete records (contacts without email, companies without organisation number), incorrect data (misspelled addresses, out-of-date phone numbers), and conflicting data (two users entering different titles for the same person). This isn't system failure. This is the system working as intended.

The MDM's mission: purity at the expense of flexibility

A Master Data Management system operates by the opposite principle: protect the integrity of the data, even if it means holding things out.

The MDM platform's primary task is to produce what's called a golden record — one authoritative, verified and deduplicated representation of a customer, a product or an entity. This record is the result of a process that collects data from multiple sources (CRM, ERP, e-commerce platform, customer service system), matches records across sources, merges and resolves conflicts according to defined priority rules, validates against defined data quality standards, and publishes the distilled, approved record back to consuming systems.

The critical point is the last step: the master register is output, not input. It's the system other systems read from, not write to. A golden record in an MDM system is protected. Direct write access — from integrations, from users, from AI agents — isn't permitted without going through the defined data quality process. This isn't bureaucracy; it's the data architecture version of the "four eyes" principle.

MDM doesn't have to be one monolithic platform, by the way. Modern implementations are often built as data products, event-based identity resolution services, or composable architectures on top of a data lakehouse. The principle is the same regardless of technology choice: data is distilled before it's distributed.

What happens when we try to combine the two

Suppose we decide to implement master register functionality directly in Dynamics 365. We're going to use the same platform to let salespeople create contacts freely and quickly (the CRM mission) while also maintaining an authoritative, clean and duplicate-free register (the MDM mission). To pull this off, we'd have to build a complex data model — separate entities for "operational contacts" and "master contacts," merge logic and status fields — on a platform where Dataverse is optimised for operational workloads, not heavy matching and governance. Merge functionality in Dynamics is relatively basic, cross-entity relationship handling across legal entities is limited, and native duplicate detection is heuristic compared to dedicated MDM engines.

Add to that complex business processes — duplicate detection, review queues, approval workflows and audit trails, in a platform where the users are primarily salespeople and customer service representatives. And complex user interfaces — end users now have to deal with the fact that "the contact we see here" isn't necessarily "the contact that counts," with UI logic that communicates data status and locked fields controlled by the master register.

The result is a system that's too complex for CRM users and too weak for a real MDM need. We've compromised both missions.

"But we can set up some data quality rules in the CRM, right?"

Yes. And we should. It's common sense to implement a minimum set of validation rules in Dynamics 365: mandatory email format, organisation number checked against a validating API, address normalisation, and simple duplicate detection on name and email. This reduces noise in the input data and makes the MDM job easier downstream.

But this is hygiene, not governance. A duplicate detection rule in the CRM catches the obvious duplicate. It doesn't catch "Kari Olsen at Acme AS branch Bergen" and "K. Olsen, Acme Bergen" entered by two different salespeople at different times. It doesn't catch that "Olsen Consulting" and "Olsen Consulting AS" are the same legal entity.

And most importantly: a validation rule in the CRM doesn't protect the master register. It just reduces the number of errors that should never have happened in the first place.

The practical conclusion

The architecture is simpler than it's often made out to be. Dynamics 365 is the system where data originates — low-threshold, inclusive and tolerant. It accommodates reality as it actually is: chaotic, incomplete and human. Optimised for real-time collaboration.

The MDM platform is the system where data is distilled. It reads from the CRM (and other sources), runs its process, and produces a register that ERP systems, reporting platforms, regulatory reports and AI models can trust. Optimised for quality and reliability.

There are MDM solutions available today that are far simpler and cheaper to implement than the large "enterprise MDM" platforms from the early 2000s. A right-sized, focused MDM tool, integrated with Dynamics 365 via standard APIs, isn't a large project. For customers with more exotic needs, a custom serverless solution — Azure Functions or other tailored API services — can also be a sensible alternative to commercial MDM tools.

Most organisations eventually build an MDM layer. The only real question is whether they do it deliberately or accidentally.

A CRM that tries to be the master register is like a warehouse trying to also be the shop window. It can technically be done. But it doesn't serve either purpose particularly well.