Master Data Management with Microsoft Dataverse

1. Introduction
2. Designing a Clean MDM Architecture with Dataverse
   1. Domain Mastering and the Single-Writer Principle
   2. Multi-Company Data Modeling
   3. Observability as a Production Requirement
3. A Realistic Positioning of Dataverse in an MDM Strategy
4. Benefits of Using Dataverse as an MDM Hub
   1. Identity and Data Uniqueness
   2. Auditing and Traceability
   3. Security and Identity Management
   4. Integration Capabilities
5. When You Should Avoid Storing Data in Dataverse
6. Multi-Company Architecture Options
   1. Option A — Single Dataverse Hub (Recommended)
   2. Option B — Dataverse per Business Cluster
   3. Option C — Registry + Data Lake Architecture
   4. Dual-Write Constraints to Consider
7. Environment Strategy and ALM
8. Data Ingestion Strategies
   1. Event / Workflow Integrations
   2. Data Pipelines
   3. Analytical Replication
   4. Excel or File-Based Ingestion
   5. API-Based Integration
9. Conflict Management and Data Ownership
10. Practical Multi-Company Ownership Examples
11. Managing Conflicts
12. Monitoring and Observability
    1. Application Monitoring
    2. Operational Analytics
    3. Dual-Write Operations
    4. Data Governance and Metadata Management
13. Conclusion

Introduction

In a multi-company environment built on Dynamics 365 Finance & Supply Chain Management, the desire for a single master data repository is completely legitimate. This is one of the core goals of Master Data Management (MDM):

• Maintain a trusted set of master data
• Apply governance rules
• Control who can create or modify data
• Distribute consistent information to consuming systems

Microsoft Dataverse can play this role if it is positioned correctly. Rather than treating Dataverse as a full “packaged MDM platform,” it should be considered an operational MDM hub.

Dataverse provides essential building blocks:

• Data persistence
• Security and identity management
• Extensibility
• Integration capabilities

However, true MDM governance must still be designed. This includes:

• Data matching and deduplication
• Survivorship rules (which system wins in case of conflicts)
• Business-level versioning
• Conflict resolution processes

A clean MDM architecture with Dataverse requires strategic decisions before implementing any integration mapping.

Designing a Clean MDM Architecture with Dataverse

Before implementing integrations, three architectural principles should be defined.

Domain Mastering and the Single-Writer Principle

Anyone who has implemented Dynamics 365 Finance & Supply Chain Management in a multi-company environment quickly encounters the same challenge:

Where should master data live?

Products, customers, vendors, addresses, hierarchies — all of these must remain consistent across legal entities and systems. Yet in most organizations:

• ERP owns some domains
• CRM owns others
• Data also exists in portals, data lakes, and external applications

Without clear governance, master data becomes fragmented.

This is where Master Data Management (MDM) comes into play.

Each data domain must have a clear ownership model.

This follows the Single Writer Principle: Only one system is responsible for writing master data for a given domain.

A typical enterprise example looks like this:

Data Domain	System of Record
Products	ERP
Customers	CRM / Dataverse
Vendors	ERP
Reference data	Dataverse

Without this rule, conflicts and inconsistencies are inevitable.

Multi-Company Data Modeling

A multi-company architecture must be aligned with the constraints of dual-write synchronization.

Dual-write supports only two mapping patterns:

• Company-specific ↔ company-specific
• Cross-company (Global) ↔ cross-company (Global)

Mixing global and company-specific entities is not supported.

Mixing these patterns breaks synchronization.

A typical design pattern is to include a Company / Legal Entity attribute referencing the cdm_companies table when modeling company-specific data in Dataverse.

This keeps the model aligned with ERP structures.

Observability as a Production Requirement

Monitoring and operational readiness should not be treated as optional features.

A production-ready architecture must include:

• Telemetry with Azure Application Insights
• Operational analytics via Power Platform Admin Center
• Data auditing using Microsoft Purview
• Capacity monitoring and alerting

These capabilities are essential for operating an MDM platform at scale.

A Realistic Positioning of Dataverse in an MDM Strategy

Master Data Management is both a set of practices and a technology stack used to:

• Define master data domains
• Consolidate records
• Govern data quality
• Distribute trusted data across systems

Within the ecosystem of Microsoft Power Platform and Dynamics 365, Dataverse is a natural candidate for an operational MDM hub because it provides:

• A relational data model
• Fine-grained security
• Server-side extensibility (plug-ins)
• Workflow automation
• Rich APIs
• Native integration with modern data platforms

It also integrates tightly with enterprise tools like:

• Azure Data Factory for data pipelines
• Power Automate for workflow automation
• Azure Application Insights for monitoring
• Microsoft Purview for governance

These capabilities make Dataverse an excellent orchestration layer for master data.

Benefits of Using Dataverse as an MDM Hub

Identity and Data Uniqueness

Dataverse supports alternate keys, allowing integrations to perform upserts without relying on internal GUID identifiers.

This is extremely useful when integrating external systems.

Auditing and Traceability

Dataverse provides built-in auditing capabilities:

• Table-level or column-level auditing
• Per-record or global audit views
• Extraction through API or SDK

This helps maintain data lineage and accountability.

Security and Identity Management

Security integrates with Microsoft Entra ID and the Dataverse role-based security model.

Features include:

• Role-based access control (RBAC)
• Business units and teams
• Privilege inheritance

However, privilege accumulation must be carefully governed to avoid excessive access rights.

Integration Capabilities

Dataverse supports multiple integration approaches depending on latency and volume requirements.

Common options include:

• Dual-write (near real-time bidirectional sync)
• Power Automate
• Azure Data Factory (ADF)
• Azure Synapse Link
• Azure Logic Apps

When You Should Avoid Storing Data in Dataverse

One misconception is that an MDM hub must store all master data.

That is not always necessary.

Sometimes Dataverse should act as a registry rather than a repository.

In these cases:

• Source systems keep their operational data
• Dataverse stores identifiers and metadata
• External data is exposed using virtual tables

If the authoritative data must remain in another system, Dataverse does not necessarily need to store a copy.

In these cases, virtual tables can expose external data as if it were stored locally.

This approach helps:

• Reduce storage costs
• Avoid unnecessary data duplication
• Keep data ownership with the source system

Multi-Company Architecture Options

There are several possible architectures when using Dataverse as an MDM hub.

Option A — Single Dataverse Hub (Recommended)

A single Dataverse environment manages master data for all companies.

This approach works best when:

• Governance is centralized
• Systems are relatively homogeneous

For company-specific data, tables should include a Company / Legal Entity dimension referencing the cdm_companies table.

This follows dual-write guidelines for legal-entity-specific entities.

Option B — Dataverse per Business Cluster

Multiple Dataverse environments may be used, typically segmented by:

• Country
• Business unit
• Subsidiary

This approach may be necessary when dealing with:

• Data sovereignty requirements
• Strict security segmentation
• Large numbers of legal entities approaching dual-write limits

Dual-write live synchronization currently supports up to 250 legal entities.

Option C — Registry + Data Lake Architecture

For high-volume scenarios, a registry architecture may be more realistic.

In this model:

• Dataverse stores only golden records and indexes
• Source systems retain operational data
• Large datasets are stored in a data lake

Virtual tables and lake integrations allow data access without replication.

Dual-Write Constraints to Consider

When designing your architecture, keep the following constraints in mind.

• ERP and Dataverse must be in the same Entra tenant
• They must also share the same Azure datacenter
• Dual-write supports up to 250 legal entities
• Cross-company sharing is not supported

Dual-write should also be treated as a distributed system:

• There are no distributed transactions
• Failures in one system may leave inconsistent states

For example, an ERP transaction cancellation may not always roll back changes in Dataverse.

This means architects must design the data model carefully

Environment Strategy and ALM

A proper environment lifecycle is critical.

Typical environments:

• Development
• Test / UAT
• Production

Deployments should rely on managed solutions.

However, remember that CI/CD pipelines deploy:

• Customizations
• Connection references
• Environment variables

They do not deploy data stored in Dataverse tables.

Initial data loads must therefore be handled separately using:

• Dataflows
• Integration pipelines
• Initial dual-write synchronization

Data Ingestion Strategies

Dataverse supports multiple ingestion approaches.

Common options include:

• Power Query Dataflows
• APIs
• Azure Data Factory pipelines
• Automation tools like Power Automate

Each tool serves a different latency and volume requirement.

Event / Workflow Integrations

Using Power Automate or Azure Logic Apps for:

• notifications
• approvals
• business workflows

Data Pipelines

Using Azure Data Factory for:

• batch synchronization
• data transformations
• ingestion pipelines

Analytical Replication

Using Azure Synapse Link to replicate Dataverse data into analytics platforms.

Excel or File-Based Ingestion

Batch ingestion from files can be implemented using Power Query.

This allows:

• Data transformations
• Cleansing
• Validation before loading

However, certain settings may unintentionally remove rows (for example, delete-missing-rows options combined with primary keys).

Careful configuration is required.

API-Based Integration

For near-real-time integrations, Dataverse Web APIs should be used.

Best practice is to perform upserts using PATCH requests with alternate keys.

When alternate keys are specified in the URL, they should not be duplicated in the request body.

Conflict Management and Data Ownership

In practice, the only sustainable model is domain-based ownership.

Each domain must define:

• Where data is created
• Where it can be edited
• How it is replicated
• How conflicts are detected and resolved

Practical Multi-Company Ownership Examples

Products

Typically mastered in ERP (F&SCM). Dataverse can enrich product data with marketing attributes or documentation.

Customers

If data originates from CRM systems or portals, Dataverse can act as the customer mastering system, while ERP consumes the data.

Vendors

Usually mastered in ERP because of financial and procurement controls.

Dataverse may support vendor onboarding workflows, but the ERP vendor ID remains the reference identifier.

Managing Conflicts

Dual-write processes transactions sequentially, but number sequences are not synchronized between ERP and Dataverse.

Multi-master scenarios therefore require:

• Prefix conventions
• ID ranges per system

This prevents identifier collisions.

Conflict handling should also be modeled as business cases, not just technical errors.

For example, conflicts can be stored in an MDM conflict management table (mdm_conflictcase) for operational teams to review.

Monitoring and Observability

Application Monitoring

Dataverse can export telemetry directly to Azure Application Insights.

This allows:

• Performance monitoring
• Diagnostics
• Alerting on thresholds

Custom code (plug-ins) should log telemetry using ILogger, which integrates directly with Application Insights.

Operational Analytics

The Power Platform Admin Center provides built-in analytics for Dataverse:

• Usage metrics
• Plug-in execution statistics
• Workflow activity
• Capacity consumption

Dataverse storage is split into three pools:

• Database
• File
• Log

Alerts can be configured when capacity approaches limits.

Dual-Write Operations

Dual-write includes operational features such as:

• Error logs
• Alert thresholds
• Notifications
• Synchronization control (play, pause, catch-up)

These features are critical for maintaining synchronization stability.

Data Governance and Metadata Management

For enterprise governance, Dataverse can be scanned by Microsoft Purview.

Purview can extract metadata such as:

• Tables
• Columns
• Data lineage

This helps organizations build a central data catalog and governance framework.

Conclusion

Using Dataverse as an operational MDM hub in a Dynamics 365 ecosystem is a powerful architectural pattern.

However, success depends less on the technology itself and more on governance design and operational discipline.

Key success factors include:

• Clear domain ownership
• Strict adherence to the single-writer principle
• Multi-company data modeling aligned with dual-write constraints
• Strong observability and operational monitoring

When implemented correctly, Dataverse becomes a central integration and governance layer, enabling consistent master data across ERP, CRM, and other enterprise systems.