CRM is not a master register, and rarely should be

It happens in nearly every implementation project. Somewhere between kick-off and go-live, the same question surfaces, usually from someone hoping to simplify the architecture: "Can't Dynamics 365 simply become our master register?"

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: make data entry as frictionless as possible.

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. Marketing should be able to import a trade-show contact list without having half the records 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 duplicate records, incomplete information, occasional inaccuracies and conflicting user input. 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 primary purpose of an MDM platform is to create what is commonly known as 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 updates (whether from integrations, users or AI agents) are typically controlled through defined governance and data-quality processes. This isn't bureaucracy; it's the data architecture version of the "four eyes" principle.

Modern MDM does not necessarily require a monolithic platform. 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 refined before it is distributed.

The difference in one table

The two missions can be summarised like this:

What happens when we try to combine the two

Suppose we decide to implement master-data functionality directly within 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 achieve this, 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 becomes too complex for CRM users and insufficient for true master-data governance. We've compromised both missions.

Scenario: A mid-sized organisation tried to make its CRM the master register by adding strict validation rules: mandatory fields on every contact, deduplication checks on save, no save without an org number. Within six months, salespeople began creating placeholder contacts to get past the rules. The CRM stayed "clean". The actual customer information moved to spreadsheets and notes. The rules did not fix the data problem. They moved it.

"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 data hygiene, not data 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 simply reduces the number of avoidable errors entering the system.

The practical conclusion

The architecture is simpler than it's often made out to be. Dynamics 365 is the system where data originates: accessible, inclusive and tolerant of imperfect information. It reflects reality as it actually exists: 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 organisations with more specialised requirements, 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. Ultimately this is about owning the data rather than owning the system.

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