What Is Microsoft Dataverse? The Complete Guide for Dynamics 365 Users (2026)

What Is Dataverse?

Microsoft Dataverse is a cloud-native, relational database platform that serves as the unified data layer for Dynamics 365, Power Platform, and the broader Microsoft business applications ecosystem. Formerly called Common Data Service (CDS), it was rebranded to Dataverse in November 2020 to reflect its broader role beyond just Dynamics 365 adoption.

At its core, Dataverse is a managed, multi-tenant database hosted on Azure SQL Database infrastructure. Unlike traditional databases you would manage yourself, Dataverse is fully managed by Microsoft—you don’t provision infrastructure, manage backups, or handle scaling. Instead, you define data structures through the platform’s UI or APIs, and Microsoft handles the rest.

Think of Dataverse as the “nervous system” of your Dynamics 365 ecosystem: every customer record in Sales, every case in Customer Service, every work order in Field Service, and every customer profile in Customer Insights lives in Dataverse tables. It’s not just a data store—it’s an application platform that enforces business logic, manages user access, tracks changes, and triggers automation.

Core Architecture: Tables, Columns, & Relationships

Dataverse organizes data into tables (similar to SQL tables), which are collections of columns (fields) and rows (records). Understanding its data model is critical for effective implementation.

Standard & Custom Tables

Dataverse comes with standard tables pre-built for common business objects:

• Account – Organizations, customers, prospects
• Contact – People associated with accounts
• Lead – Sales opportunities in early stages
• Opportunity – Active sales pipeline
• Case – Customer service tickets
• WorkOrder – Field service jobs
• Invoice – Financial documents

Beyond standard tables, you can create custom tables to capture industry-specific or organization-specific data. Custom tables inherit the same security, audit, and event capabilities as standard tables.

Columns & Data Types

Each table contains columns that define what data can be stored. Dataverse supports diverse data types:

• Text: Single/multi-line, email, phone, URL
• Numbers: Integer, decimal, currency
• Dates: Date only, date & time, timezone aware
• Lookups: References to records in other tables (foreign keys)
• Choices: Picklists (single or multi-select)
• Calculated & Rollup: Computed fields that aggregate related data
• File & Image: Binary data with size limits

Columns have properties that enforce data quality: required/optional, unique constraints, maximum lengths, and business rules (conditions that must be met before saving).

Relationships & Data Integrity

Dataverse enforces referential integrity through three relationship types:

• One-to-Many: One Account has many Contacts (the most common relationship type)
• Many-to-One: Multiple Cases point to a single Account
• Many-to-Many: Contacts can belong to multiple Campaigns (junction table managed by Dataverse)

When you delete a parent record, cascading rules determine what happens to child records: delete them, reassign them, or prevent deletion if children exist.

Solutions & Metadata

Dataverse organizes customizations into solutions—versioned, transportable packages of metadata that include tables, forms, views, plugins, and workflows. Solutions enable environment-to-environment deployment (dev → test → production) and version control. This is critical for managing customizations at scale.

How Dynamics 365 CRM Apps Use Dataverse

Dynamics 365 customer-facing applications are built entirely on top of Dataverse. This architecture means:

Dynamics 365 Sales stores all accounts, contacts, leads, and opportunities in Dataverse. When a salesperson updates a pipeline stage, that change is persisted to a Dataverse table. The Sales app is essentially a UI layer that reads from and writes to Dataverse.

Dynamics 365 Customer Service manages cases in Dataverse, including case relationships, queues, entitlements, and SLAs. Knowledge base articles are stored in Dataverse tables. When an agent resolves a case, the change updates the Dataverse record in real-time.

Dynamics 365 Field Service coordinates work orders, resources, scheduling, and equipment records all stored in Dataverse. Mobile technicians can go offline and sync changes when reconnected because the Field Service mobile app caches Dataverse data locally.

Dynamics 365 Customer Insights (formerly Customer Insights – Data) runs analytics and builds customer profiles in Dataverse, creating unified customer records that sync back to Dynamics 365 Sales and Customer Service.

The key insight: Dynamics 365 CRM apps do not own their own databases. They delegate all data persistence to Dataverse. This enables multiple apps to work with the same data simultaneously without duplication.

Dynamics 365 Finance & Operations: Virtual Entities & Dual Write

Dynamics 365 Finance & Operations (F&O) is built on a different database stack (SQL Server / Azure SQL) and does not store data natively in Dataverse. However, Dataverse connects to F&O through two integration patterns:

Virtual Entities

Virtual entities are read-only Dataverse table representations of F&O data. When you query a virtual entity in Dataverse, it fetches the data from F&O in real-time via API calls. Virtual entities are useful for:

• Displaying F&O product catalogs in Dataverse-based apps
• Pulling F&O inventory levels into Dynamics 365 Sales
• Creating Power Apps that display F&O data without duplication

Performance is slower than native Dataverse tables because each query makes an API call to F&O. Virtual entities are not designed for high-frequency reporting.

Dual Write

Dual write enables bi-directional synchronization between Dataverse and F&O tables. When you create or update a record in either system, the change automatically syncs to the other. Dual write is used for:

• Syncing customer master data (accounts, contacts) between Sales and F&O
• Syncing product master data from F&O to Dataverse-based apps
• Keeping supply chain data aligned across systems

Dual write uses a message queue (Azure Service Bus) to guarantee eventual consistency, with retry logic for transient failures. Conflicts are resolved based on configurable rules (F&O wins, Dataverse wins, or custom logic).

Business Central: Dataverse Integration

Dynamics 365 Business Central (the SMB version of F&O) connects to Dataverse through a data synchronization service that provides one-way or two-way sync of core entities: customers, vendors, items, and general ledger accounts.

Business Central users can leverage Power Apps, Power Automate, and Power BI to create rich experiences that combine Business Central data with Dataverse-native data. However, Business Central’s primary data store remains its own SQL database—Dataverse is a complementary integration layer, not the native database.

Security Model: Role-Based Access Control & Data Ownership

Dataverse enforces fine-grained security at multiple levels:

Role-Based Access Control (RBAC)

Dataverse security roles define what users can do with each table and record type. A role specifies permissions for:

• Create, Read, Update, Delete (CRUD): For each table
• Scope levels: User (own records only), Business Unit, Parent Business Unit, Organization (all records)
• Record types: For example, a salesperson role might have Create/Read/Update on Accounts but only Read on Products

Business Units & Hierarchies

Users are assigned to business units, which can form hierarchies (e.g., North Region > East District > Boston Office). Security roles respect business unit relationships, enabling regional managers to see all records in their hierarchy without manual role assignment.

Field-Level Security

Beyond table-level permissions, Dataverse supports field-level security: certain sensitive columns (e.g., salary, SSN) can be restricted to specific roles. If a user’s role does not have permission to a field, that field is masked or hidden in the UI.

Record-Level Sharing & Ownership

Each record has an owner (a user or team). Users can see and modify records they own based on their role permissions. Managers can share records with subordinates or colleagues to grant additional access without changing role assignments.

Audit & Change Tracking

Dataverse maintains an audit log of all changes: who modified each record, when, and what changed. This is critical for compliance, fraud detection, and troubleshooting. Change tracking also enables efficient data synchronization (only modified records are synced).

API Surface: REST, SOAP, & SDKs

Dataverse does not expose direct SQL database access. Instead, it provides APIs that abstract the underlying schema and enforce security, business logic, and consistency rules:

REST/OData Web API

The REST Web API is the modern, recommended approach for integrating with Dataverse. It uses OData (Open Data Protocol) standards for querying, filtering, and pagination:

• Create records: POST to /tables/accounts
• Read records: GET from /tables/accounts(id)
• Update records: PATCH to /tables/accounts(id)
• Delete records: DELETE /tables/accounts(id)
• Query with filters: GET /tables/accounts?$filter=name eq ’Contoso’

The Web API enforces security, runs business rules, and triggers plugins before persisting changes. It also supports batch operations (multiple CRUD actions in one request).

Organization Service (SOAP)

The Organization Service is the legacy SOAP-based API, still used in some enterprise scenarios where SOAP is required for compliance or integration architecture. It provides the same functionality as the REST API but with different syntax.

TypeScript & JavaScript SDKs

Microsoft provides official SDKs in TypeScript for Power Automate cloud flows, Power Apps portals, and client-side scripting. These SDKs simplify API calls and provide intellisense for table names and columns.

Power Automate & Power Apps

These low-code/no-code platforms provide visual connectors to Dataverse that abstract away API complexity. Non-developers can build integrations without writing code.

Event System: Plugins, Webhooks & Business Events

Dataverse triggers automation in response to data changes. This event-driven architecture enables real-time workflows without polling:

Plugins

Plugins are .NET assemblies that execute custom code in response to Dataverse events: Create, Update, Delete, Retrieve. Plugins run synchronously (before the change is persisted, in a “pre-image” stage) or asynchronously (after persistence, in a “post-image” stage).

Use plugins to validate data, enforce business rules, call external APIs, or prevent changes when conditions are not met.

Webhooks

Webhooks are HTTP POST requests sent to external endpoints when Dataverse records change. Unlike plugins (which run in Dataverse’s process), webhooks enable decoupled integration with external systems—the external system does not need to be available for the Dataverse change to complete.

Webhooks are ideal for triggering cloud services (Azure Functions, AWS Lambda, third-party SaaS APIs).

Business Events

Business events are high-level Dataverse notifications (e.g., “opportunity won” or “customer created”) that can trigger Power Automate flows. Business events abstract away technical details and provide semantic meaning to changes.

Azure Service Bus Integration

For high-volume integrations, Dataverse can publish events to Azure Service Bus topics, enabling reliable, scalable event streaming to external systems.

Environments: Production, Sandbox, Developer

Dataverse instances are organized into environments, each with its own database, security configuration, and customizations:

• Production: Live environment where end-users work. Changes require careful testing before promotion.
• Sandbox: Test/staging environments isolated from production. You can make changes, test them, and then promote to production via solutions.
• Developer: Personal development environments where individual developers can experiment without impacting others.

Each environment consumes capacity: storage (measured in GB), API requests (daily limits), and Power Automate flow runs. Standard subscriptions include base capacity; additional capacity is purchased by the GB or as add-ons.

Dataverse for Teams: Lightweight Database in Microsoft 365

Dataverse for Teams is a simplified version of Dataverse included with Microsoft 365 subscriptions (Teams, Office, SharePoint). It enables small teams to build Power Apps and Power Automate flows with a 2 GB database limit, no separate licensing, and simpler administration.

Dataverse for Teams lacks some advanced features of standard Dataverse (no plugins, limited API access, no Dynamics 365 integration) but is ideal for departmental apps and quick prototypes.

Azure Synapse Link: Real-Time Analytics

Azure Synapse Link for Dataverse enables continuous, one-way export of Dataverse data to Azure Synapse Analytics or Microsoft Fabric. Changes in Dataverse are automatically replicated to a data lake, enabling real-time reporting and machine learning without impacting Dataverse performance.

This is powerful for organizations that need advanced analytics: combine Dataverse CRM data with supply chain data from F&O, financial data from other systems, and run predictions using AI/ML.

Licensing: Cost Model & Capacity Planning

Dataverse licensing varies by use case:

Included with Dynamics 365

Dynamics 365 CRM app subscriptions (Sales, Customer Service, Field Service, Customer Insights) include Dataverse capacity: typically 10 GB storage + unlimited API calls for licensed app users.

Standalone Dataverse

If you purchase Dataverse independently (for Power Apps or custom integrations without Dynamics 365), capacity is billed as:

• Storage: $40 USD per GB per month (first 1 GB free for certain subscriptions)
• Database transactions: Unlimited for Dynamics 365 users; metered for other scenarios

Capacity Planning

Monitor your capacity using the Power Platform admin center. One Dynamics 365 Sales user typically consumes 100–500 MB of storage, depending on data volume and history.

Dataverse vs. SharePoint, SQL Database & Azure SQL

Dataverse vs. SharePoint

SharePoint is a document management and collaboration platform. It stores files, lists, and provides permissions. Dataverse is a relational database designed for transactional business data.

Choose Dataverse if: You need a structured database with relationships, business logic, and role-based access control.

Choose SharePoint if: You are managing documents, enabling team collaboration, or storing unstructured content.

The two often work together: Dataverse stores customer records, SharePoint stores customer files and documents.

Dataverse vs. SQL Database / Azure SQL

SQL Database is a traditional relational database you manage yourself (or through Azure). Dataverse is a managed, application-oriented database with built-in security, auditing, and APIs.

Advantages of Dataverse:

• No infrastructure management (Microsoft handles patches, backups, scaling)
• Built-in security, auditing, and change tracking
• APIs and low-code/no-code tools (Power Apps, Power Automate)
• Seamless integration with Dynamics 365, Power Platform, and Microsoft business apps

Advantages of SQL Database:

• Unlimited storage and direct SQL query access (via connection strings)
• Lower cost for large-scale data warehousing
• Full database administration control (indexes, tuning, security policies)
• Established patterns and tools in the SQL ecosystem

Hybrid approach: Use Dataverse for operational Dynamics 365 data, Azure Synapse Link to sync to Data Lake / Synapse for analytics and reporting.

Industry Best Practices

• Model your tables carefully: Denormalization and unnecessary columns consume storage. Design relationships thoughtfully.
• Use security roles consistently: Avoid over-sharing records. Leverage business unit hierarchies and role-based access control.
• Monitor capacity: Set up alerts for storage consumption and plan for growth.
• Version customizations with solutions: Never make ad-hoc changes. Use solution versioning for traceability and rollback.
• Test plugins & webhooks extensively: Event handlers that fail can block data changes. Implement error handling and logging.
• Archive old data: For compliance and performance, move historical data to separate tables or Azure Synapse.
• Use the Web API for integrations: Avoid direct database connections. APIs enforce business logic and security.

Summary

Microsoft Dataverse is the foundational database layer for Dynamics 365, Power Platform, and the broader Microsoft business applications ecosystem. It provides a managed, API-first, secure relational database with built-in event handling, auditing, and role-based access control—enabling organizations to unify customer data, automate business processes, and scale without managing infrastructure.

Whether you’re implementing Dynamics 365 Sales, building custom Power Apps, or integrating Finance & Operations, understanding Dataverse architecture, security, and APIs is essential for success. By following best practices around table design, security governance, and capacity planning, you can build robust, scalable applications on Dataverse that serve as the central data hub for your organization.