What Is Microsoft Dataverse? The Shared Data Layer Explained

What Microsoft Dataverse actually is

Microsoft Dataverse is the cloud (SaaS) data platform — the data foundation of the Microsoft Power Platform — that securely stores and manages the business data used by Dynamics 365 and Power Apps. You do not install a database engine or patch a server; Microsoft runs it on Azure and exposes it as a managed service.

Data inside Dataverse is organized into tables (previously called 'entities'), each containing rows (records) and columns (fields, or attributes). It ships with a base set of standard tables for common business concepts — accounts, contacts, leads, tasks — and you can add custom tables for anything the standard schema does not cover.

The defining trait is that Dataverse is metadata-driven: business rules, calculated columns, relationships, and logic are defined once inside Dataverse itself and then reused across every app that touches the data. The schema and the logic live with the data, not bolted onto each app separately.

• →SaaS data platform on Azure — no database engine to install or patch
• →Data organized into tables (formerly 'entities'), with rows and columns
• →Ships with standard tables (accounts, contacts, leads) plus support for custom tables
• →Metadata-driven: rules, relationships, and logic defined once and reused everywhere

How Dataverse relates to the Power Platform

Dataverse is not a standalone product you buy by itself — it is the data layer that the rest of the Power Platform sits on. Power Apps, Power Automate, Copilot Studio, and Power BI all read and write Dataverse tables, and the relationships, rules, and security defined in Dataverse apply consistently regardless of which app is doing the accessing.

That arrangement is what makes the low-code promise credible. A model-driven app is essentially a UI over a Dataverse table; a Power Automate flow triggers on a Dataverse row event; a Copilot in Copilot Studio can answer questions grounded in Dataverse data; Power BI reports connect to the same tables. One data model, many consumption surfaces.

Because the logic lives in Dataverse, a validation rule or security constraint you define once is enforced whether a record is touched by Dynamics 365, a canvas app, an automated flow, or Copilot. There is no need to re-implement the rule in each client.

• →Dataverse is the data layer underneath Power Apps, Power Automate, Copilot Studio, and Power BI
• →Model-driven apps are essentially a UI over Dataverse tables
• →Rules and security defined in Dataverse are enforced across every consuming app
• →One data model serves many surfaces — no per-client rule duplication

How Dataverse relates to Dynamics 365

This is the relationship that confuses most buyers. The customer-engagement side of Dynamics 365 — Sales, Customer Service, Field Service, and Human Resources — stores and secures its data natively in Dataverse. When you license Dynamics 365 Sales, you are effectively licensing a pre-built application that runs on Dataverse tables.

That means a Power App built against Dataverse can read and write the same records Dynamics 365 Sales uses, with no separate integration layer. The accounts, contacts, and cases live in one place, and the metadata, logic, and security defined in Dataverse apply consistently regardless of which app accesses them.

The Finance and Operations side is different. Dynamics 365 Finance, Supply Chain Management, and Commerce do NOT natively store their data in Dataverse. They run on their own database and require specific integration — dual-write or the Data Integrator — to surface that data in Dataverse so the rest of the Power Platform can reach it. Microsoft's own Power Apps documentation notes that 'Finance and Operations apps currently require the configuration of the Data Integrator to make your business data from Finance and Operations apps available in Dataverse.' Treat 'Dynamics 365 runs on Dataverse' as true for CE apps and only conditionally true for F&O apps.

The relational data model and what comes with it

Under the marketing language, Dataverse is a relational database with strongly typed columns, typed relationships (one-to-many, many-to-one, many-to-many), and referential integrity. That puts it closer to a proper database than to a spreadsheet or a flat list — which is the point.

On top of the relational core, Dataverse layers capabilities that you would otherwise have to build: standard and custom tables, calculated and rollup columns, business rules that validate data without code, business process flows that guide users through staged work, and reusable choice (option set) lists.

It also supports virtual tables, which surface external data as if it were native Dataverse — useful when you want a unified app experience without copying data in. Importing data is supported via Power Query, Excel, or CSV, and reporting is handled through Power BI and a managed data lake, all on the same secure data model.

• →Relational database with typed columns and enforced relationships
• →Calculated and rollup columns, business rules, and business process flows built in
• →Virtual tables surface external data without copying it in
• →Power BI reporting and a managed data lake on the same model

The Dataverse security model, in plain English

Dataverse security is role-based and is active only in environments that have a Dataverse database. It stacks several layers so that data access is controlled at authentication, at the environment boundary, at the role, and at the field.

The chain runs: Microsoft Entra ID (formerly Azure AD) handles authentication; licensing is the first gate; environments act as security boundaries; security roles carry eight privileges — Create, Read, Write, Delete, Append, Append To, Assign, and Share — across four access levels: User, Business Unit, Parent:Child Business Units, and Organization; business units segment the org; record ownership is either Organization-owned or User/Team-owned; column-level (field-level) security protects sensitive fields; and manager or position hierarchies model reporting lines.

The reason this matters is that the rules are defined and enforced centrally. The same security applies whether a record is touched by Dynamics 365, a custom Power App, a Power Automate flow, or Copilot — there is no per-client re-implementation. One caveat from Microsoft's own guidance: privilege grants are accumulative, with the greatest access prevailing, so broad Organization-level read cannot be narrowed later by hiding a single record.

• →Role-based security, active only in environments that have a Dataverse database
• →Eight privileges (Create, Read, Write, Delete, Append, Append To, Assign, Share) across four access levels
• →Business units segment the org; ownership is Organization-owned or User/Team-owned
• →Column-level security and hierarchies add field- and reporting-line control

Licensing and capacity: what an SME actually pays

You do not buy Dataverse by itself; you license an app or a Power Platform plan that includes the right to use it. For SMEs, the two most common entry points are Power Apps Premium at $20 per user/month (which includes Dataverse, premium connectors, and unlimited app use for the licensed user) and the Dynamics 365 first-party apps — Sales, Customer Service, Field Service — which run on Dataverse natively.

Capacity is tracked across three pools: Database capacity (structured table data and metadata), File capacity (attachments, images, notes), and Log capacity (audit history and plug-in trace logs). Microsoft increased the default per-tenant Dataverse entitlements for the customer-engagement apps in early 2026 — for example, Dynamics 365 Sales Enterprise now ships with roughly 30 GB Database and 40 GB File at the tenant level — but entitlements vary by product and change over time. Always verify live totals in the Power Platform admin center (Resources → Capacity) before budgeting, and plan for overage at roughly $40 per GB/month for additional Database capacity.

The practical SME trap is that storage consumption is uneven: attachments and image-heavy tables burn File capacity, while audit logging and plug-in traces quietly fill Log capacity. A small org running heavy email attachment capture can outgrow its entitlements faster than its row count suggests.

• →Power Apps Premium at $20/user/month is the most common SME entry point to Dataverse
• →Three capacity pools: Database, File, and Log — each tracked and billed separately
• →CE apps now ship with materially more default per-tenant Dataverse storage (e.g., ~30 GB DB / 40 GB File for Sales)
• →Overage runs ~$40/GB/month for Database; verify live totals in the Power Platform admin center

Does your SME actually need Dataverse?

For most SMEs, Dataverse is not a decision you make in isolation — it arrives as a consequence of choosing Dynamics 365 customer-engagement apps or committing to Power Apps for custom model-driven apps. If you license Dynamics 365 Sales, Customer Service, or Field Service, your data is in Dataverse whether or not you think about it; the question is only how well you govern it.

The case for engaging with Dataverse directly is strong when: you want custom apps or flows that reuse the same rules and security as your Dynamics 365 data; you need a single source of truth across sales, service, and operations; or you are building Copilot experiences grounded in structured business data. The case against over-investing is when your core ERP is Business Central or F&O (neither stores its data natively in Dataverse), you have no plans for custom Power Apps, and a simpler data layer (SQL Server, SharePoint lists, or even Odoo's native PostgreSQL) meets your needs without the licensing overhead.

Because Flectic implements both Dynamics 365 and Odoo, we are platform-neutral on this: some SMEs genuinely benefit from a Dataverse-centric architecture, and others are better served by keeping their data inside their ERP and using lighter automation. The right answer depends on your app roadmap, your tolerance for dual-write setup and tuning if you run F&O, and whether the productivity gains from Power Platform justify the per-user licensing.

• →Dataverse arrives automatically with Dynamics 365 CE apps — you govern it, you don't choose it
• →Worth leaning in when you want custom apps, flows, or Copilots reusing the same rules and security
• →Lower priority if your ERP is BC or F&O and you have no custom Power Apps roadmap
• →Platform-neutral guidance: some SMEs win with Dataverse-centric architecture, others do not