What is Microsoft Dataverse?

Microsoft Dataverse is the relational data service underneath the Dynamics 365 CRM apps and the Power Platform. It provides tables, columns, relationships, security, and business logic through a managed cloud service that developers and makers interact with through a consistent metadata layer — never through raw database access.

Dataverse is not a database in the classical sense. It is a relational data platform with a rich security model, a workflow engine, integrated audit, first-class metadata, an event grid, and a native REST API. Underneath it uses Azure SQL, Azure Data Lake, and other Azure primitives, but you don't work with any of those directly. You work with Dataverse.

Why it exists

Historically the CRM-lineage Dynamics 365 apps (Sales, Customer Service, Field Service) ran on a product called the Common Data Service (CDS), itself the successor to the Dynamics CRM Xrm platform. In 2020 Microsoft rebranded CDS to Dataverse and repositioned it as the shared data foundation for the Power Platform, not just for the Dynamics 365 apps.

The strategic bet is that one data model, one security model, one API surface makes it dramatically cheaper to build the second, third, and tenth business application on the same tenant. Every Dynamics 365 CRM app runs on Dataverse. Every custom Power App can extend the same tables. Every Power Automate flow can trigger on events raised by that shared data.

What Dataverse gives you

Tables and columns. Structured, typed data with all the standard column types (text, number, currency, date, choice, lookup) plus rich types (file, image, formula, calculated, rollup). Custom tables can be added with a maker experience or through metadata code.

Relationships. One-to-many, many-to-many, and hierarchical, with cascade rules on parent behaviour (share, assign, delete, merge). Related-table joins in queries are first-class.

Security model. Layered role-based, row-level, hierarchical, and field-level security. Business units carve the tenant into scopes; owner and access teams share records with subsets of users; roles define what each user can do inside their scope. Deep, well-thought-out, occasionally intricate — but sufficient for most enterprise security requirements without custom code.

Business logic layers. Business rules (declarative validation), workflows (classic, deprecated in favour of flows), plug-ins (server-side .NET code that fires on events), Power Automate flows, and Power Fx formulas for calculated columns and business logic. The right layer for a given piece of logic depends on performance, upgradeability, and complexity.

Events. Every row change raises an event that other tables, plug-ins, flows, and Azure services can subscribe to. This is what makes Dataverse a reactive platform rather than a static store.

Audit. Row-level and column-level change history, retained per environment configuration, accessible through the audit APIs. Regulatory requirements that demand "when did this field change and who changed it" have a native answer.

Web API. REST endpoints for every table, generated from the metadata layer, versioned per platform release. Native OData query semantics; batch operations; change-tracking; alternate keys. The primary integration surface.

The extended Dataverse family

Beyond the core relational store, Dataverse ships a family of specialised storage patterns:

Elastic tables. NoSQL-style storage for high-volume, high-throughput scenarios — IoT telemetry, event logs, session data. Different consistency guarantees, different pricing, same API surface.

Virtual tables. Federated data that stays in its source system (a SQL Server, a REST API, a SharePoint list) and appears as a Dataverse table for read (and often write) purposes. Removes the need to synchronise data into Dataverse for scenarios where the source system is the truth.

File and image columns. Blob storage attached to records, with the same security model applied to the blobs as to the record. Suitable for document attachments, product images, work-order photos.

Dataverse search. Full-text and metadata search across all tables in the environment, with security trimming so users see only rows they can access — see Dataverse search vs Quick Find for when each of the two mechanisms actually gets used.

Dataverse for Teams. A lightweight Dataverse that ships free inside Teams — a subset of the platform for lightweight scenarios where a team needs a shared data-driven app without a full Dataverse environment.

Where Dataverse fits under Dynamics 365

Every CRM-lineage Dynamics 365 app is a pre-built collection of Dataverse tables plus the model-driven UI on top. Account, Contact, Opportunity, Lead, Case, Work Order, Project — these are Dataverse tables that the Dynamics 365 apps pre-configure. A custom table added to the same environment is architecturally identical — it participates in the same security, relationships, workflows, and API surface.

This is the reason extending Dynamics 365 uses exactly the same tools a maker would use for a fresh Power App. The developer / consultant / admin community can be the same community; the skills transfer bidirectionally.

The Finance and Operations apps (Finance, SCM, Commerce, Human Resources, Project Operations resource-mode) do not run on Dataverse natively — they have their own AX-lineage data model. Integration between F&O and Dataverse is through Dual-write, a real-time bidirectional sync that makes selected F&O entities available as Dataverse tables (and vice versa). The strategic direction is toward tighter Dataverse integration, but F&O is not "on Dataverse" in the way the CRM apps are.

Environments

A Dataverse instance lives in an environment — a logical container with its own database, users, security roles, and app inventory. A tenant has a default environment (for personal productivity apps that shouldn't touch enterprise data) and however many additional environments the customer chooses to create for dev, test, production, and specific projects.

Environment strategy is one of the primary architecture decisions in a Dataverse deployment. Too few environments and dev / test / prod bleed into each other; too many and administration overhead multiplies. See the environment-strategy guide for the working patterns.

Managed environments is a paid tier that adds sharing controls, weekly usage reports, solution checker enforcement, and pipelines. Meant for organisations with a wider maker community that need centralised governance.

Solutions and ALM

Every customisation of Dataverse — a new table, a modified column, a business rule, an app, a flow — is packaged into a solution. Solutions move between environments as unmanaged (editable in the destination, for dev use) or managed (locked, for test and production).

Solution layers show how multiple solutions interact when they touch the same object. Solution checker validates a solution before deployment. Solution pipelines deploy them from source to target through the Power Platform admin center or through Azure DevOps / GitHub Actions with the pac CLI. Deep solution-management skill is the primary technical craft in professional Dataverse work.

The competitive picture

The most obvious comparison is to Salesforce Platform (the platform under Salesforce Sales Cloud and Service Cloud). Both are opinionated business-app platforms. Both have first-class metadata, security, business logic, and API surfaces. Salesforce Platform is more mature in some places (declarative development experience, deep ISV ecosystem); Dataverse wins on Microsoft 365 integration, on Copilot Studio integration, and increasingly on pricing for Microsoft-shop customers.

Oracle APEX, ServiceNow platform, and various low-code platforms (OutSystems, Mendix, Retool) share some concepts. None of them ship as the data foundation under a full Dynamics 365 CRM stack.

Licensing

Dataverse is licensed by environment (database size, file storage, log storage) plus by user (Power Apps user licences, Dynamics 365 user licences that entitle users to specific tables). It is one of the more intricate pricing areas in Microsoft — worth reading the current licensing guide before committing.

Every Dynamics 365 licence includes rights to use the CRM-lineage app's Dataverse tables in custom apps and flows. Adding new custom tables that aren't part of the Dynamics 365 licence typically requires additional Power Apps licences.

The short version

Dataverse is the relational data platform under the Dynamics 365 CRM apps and the Power Platform. Tables, columns, relationships, security, business logic, events, audit, REST API — all in one managed service. It is more than a database and less than a general-purpose PaaS; it is opinionated for building business apps quickly, governing them centrally, and integrating them with Microsoft 365 and Dynamics 365. If you build on Microsoft business apps, you spend time in Dataverse.

When Dataverse is the wrong fit

For a single canvas app with one or two makers and a spreadsheet-sized dataset, provisioning a Dataverse environment and licensing its capacity is more ceremony than the workload needs — a SharePoint list or an Excel-backed connector gets the same app built faster and cheaper. At the other end, workloads that are fundamentally high-volume and transactional rather than relationship-and-business-logic-shaped — a raw telemetry pipeline, a pure event-sourcing system, an analytics warehouse — usually fit a general-purpose Azure data store better than Dataverse's opinionated relational layer, even inside an otherwise Microsoft-first architecture; elastic tables narrow that gap for some scenarios but don't erase it. And for teams already deep in the Salesforce ecosystem with no Dynamics 365 app in the plan, adopting Dataverse purely as a standalone platform is rarely the reason to introduce it — it earns its keep as the shared foundation under Dynamics 365 and the Power Platform, not as a database chosen in isolation.

First-time buyer checklist

• Workload shape. Confirm the app is genuinely relationship-and-business-logic-shaped (records, roles, workflows) rather than a raw high-volume data problem better solved with a general-purpose store.
• Environment strategy. Decide dev/test/prod environment topology before building — see the environment-strategy guide; retrofitting environment boundaries after makers have built directly in one shared environment is disruptive.
• Security model. Map business units, security roles, and owner/access teams to your actual organisational structure before the first table is created; security design bolted on afterward means re-scoping existing records.
• Licensing. Confirm which tables each user's licence entitles them to — a Dynamics 365 licence covers that app's own tables, and new custom tables outside it typically need additional Power Apps licences.
• F&O boundary. If Finance or Supply Chain Management is in scope, plan for dual-write rather than assuming those apps' data already lives in Dataverse — they don't, natively.
• Managed Environments. For a maker community beyond a handful of people, budget for Managed Environments (sharing controls, solution checker enforcement, usage reports) rather than discovering the governance gap after sprawl has already happened.

Where to go next

Start with data model fundamentals and the security model, then the logic layer in plug-ins explained. The operational container is Power Platform environments and the deployment unit is ALM with managed solutions. When the API talks back, Dataverse Web API errors decodes it.