What Is Microsoft Dataverse? The Shared Data Layer Explained

What Microsoft Dataverse actually is

Microsoft Dataverse is a cloud, metadata-driven relational data service on Azure — the shared data layer underneath the Power Platform and Dynamics 365's customer-engagement apps. It securely stores business data in tables, with the relationships, business rules, and security defined once and enforced across every app that touches the data.

If you searched the bare word 'dataverse' or 'data verse' and landed here, note there are two unrelated products that share the name. Microsoft Dataverse (this page) is a commercial cloud database service for business apps. The Dataverse Project at dataverse.org is a completely separate, open-source research-data repository developed at Harvard's Institute for Quantitative Social Science (IQSS), used by academics worldwide to share, preserve, cite, and analyze research datasets — it has nothing to do with Microsoft, the Power Platform, or business software. Every reference on this page is to Microsoft Dataverse.

Microsoft's own documentation defines Dataverse plainly: 'Dataverse lets you securely store and manage data that's used by business applications. Data within Dataverse is stored within a set of tables.' You do not install a database engine or patch a server; Microsoft runs it on Azure and exposes it as a managed service.

Is Dataverse a database? Yes — and more than one. Underneath the marketing language, Dataverse is a relational database running on Azure as a managed service, with typed columns, enforced relationships, and referential integrity. But it is not a single database engine: table data is persisted across several Azure data services — Azure SQL Database for structured relational data, plus Azure Storage and Cosmos DB for files, logs, and elastic tables — all orchestrated and presented to you as one logical store. Standard tables (accounts, contacts, custom entities) run on Azure SQL for strong consistency and transactional joins; elastic tables, built for massive, spiky, time-series, or log-style workloads, run on Azure Cosmos DB and scale horizontally using a PartitionId you choose. You never see that plumbing; you interact with tables, columns, and relationships through makers' tools and APIs. The recurring community thread 'Dataverse is not a database' is really arguing that point: it is a database plus a metadata, logic, and security platform layered on top.

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, patch, or tune
• →Data persisted across Azure SQL, Azure Storage, and Cosmos DB, exposed as one logical store
• →Standard tables run on Azure SQL; elastic tables run on Azure Cosmos DB for horizontal scale
• →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
• →Not to be confused with The Dataverse Project (dataverse.org) — Harvard's unrelated open-source research-data repository

Official Dataverse docs and learning resources

The authoritative reference for Microsoft Dataverse is Microsoft Learn. If you came looking for 'Dataverse docs,' these are the primary entry points every maker, admin, and developer should bookmark. The conceptual documentation hub covers everything from creating your first table to the deep developer reference; the free 'Describe Microsoft Dataverse' training module is the fastest self-paced introduction; the Power Platform admin center is where environments, security roles, and capacity (the Database, File, and Log pools) are managed; and the Power Apps maker portal at make.powerapps.com is where you model tables, columns, relationships, and business rules and assemble model-driven apps.

For developers, the Dataverse developer documentation is the source of truth for the Web API and SDK, service-protection API limits, plug-ins, and elastic tables. Treat Microsoft Learn as the canonical reference whenever a vendor blog (including this guide) and the official docs disagree — Microsoft updates those pages as the platform evolves.

• →Microsoft Learn is the canonical reference — bookmark it over any third-party blog
• →The 'Describe Microsoft Dataverse' training module is the fastest free introduction
• →The admin center manages environments, capacity, and API request usage
• →The maker portal (make.powerapps.com) is where tables, columns, and apps are built
• →Developer docs cover the Web API, SDK, elastic tables, and plug-ins

Dataverse architecture: tables, columns, and relationships

Dataverse is organized around three building blocks: tables, columns, and relationships. A table (formerly called an 'entity') is a set of rows (formerly 'records') and columns (formerly 'fields' or 'attributes'). Each column is designed to store a specific type of data — text, number, date, choice, or lookup. Microsoft updated this terminology in November 2020 to be more intuitive: 'entity' became 'table,' 'field/attribute' became 'column,' 'record' became 'row,' and 'option set' became 'choice.'

Dataverse ships with a base set of standard tables — accounts, contacts, leads, tasks, opportunities — designed around common business scenarios, and you can add custom tables for anything the standard schema does not cover. Data is imported via Power Query, Excel, or CSV. On top of the relational core, Dataverse layers 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.

Relationships tie the model together. Microsoft's documentation is explicit that there are only two relationship types: one-to-many (1:N) and many-to-many (N:N). A 'many-to-one' (N:1) relationship is simply a 1:N viewed from the child table's perspective. Adding a lookup column to a table creates a 1:N relationship, letting you associate many child rows with a single parent row. A N:N relationship uses a special intersect (relationship) table so that many rows of one table can relate to many rows of another.

Relationships also enforce data integrity through cascading behavior. When a parent row is deleted, assigned, shared, or merged, you control what happens to its children via behaviors like Cascade All, Cascade Active, Cascade None, Remove Link, Restrict, and Cascade User Owned. A 'parental' relationship cascades assign, delete, share, and reparent automatically — which is how reassigning an account can hand off all its tasks without manual work.

• →Tables (formerly entities) hold rows (records) and columns (fields/attributes)
• →Standard tables ship built-in; custom tables cover the rest; terminology was modernized in 2020
• →Only two relationship types exist: 1:N and N:N — N:1 is just a 1:N from the child's side
• →Lookup columns create 1:N relationships; N:N uses an intersect table
• →Cascading behaviors (Cascade All, Restrict, Remove Link, etc.) preserve referential integrity

How Dataverse powers Power Apps, Power Automate, and Power BI

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. Microsoft's documentation states that Dataverse 'allows data to be integrated from multiple sources into a single store, which can then be used in Power Apps, Power Automate, and Power BI.'

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 (created, updated, deleted); a Copilot in Copilot Studio can answer questions grounded in Dataverse data; and Power BI connects directly to Dataverse tables to publish reports. 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. Power BI integration is particularly direct: Dataverse exposes a native connector so Power BI Desktop can build reports against live Dataverse data without a separate data warehouse.

• →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
• →Power Automate flows trigger on Dataverse row events (create, update, delete)
• →Power BI connects directly to Dataverse via a native connector — no warehouse required
• →Rules and security defined in Dataverse are enforced across every consuming app

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 verbatim 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.

Dataverse vs Azure SQL: when to use which

A frequent question is whether to build on Dataverse or on a plain Azure SQL Database. They overlap but serve different purposes. Dataverse is a governed, application-aware data platform tightly integrated with Power Platform — it bundles a relational database with metadata-driven business rules, role-based security, business process flows, and built-in connectors. Azure SQL Database is a general-purpose managed relational database where you design the schema, write the logic, and build the application layer yourself.

The practical guidance from Microsoft's own teams is to use both when it fits: Dataverse handles your operational business data and Power Platform workflows, while SQL Server powers analytics, reporting, or high-throughput workloads that need raw T-SQL control. Dataverse is 'more than a database' — it stores table data in Azure SQL but also uses Azure Storage and Cosmos DB — so you trade fine-grained control for faster low-code delivery and centralized logic.

Choose Dataverse when you need a governed operational system of record that Power Apps, Power Automate, and Copilot can reach natively, and when you want security, validation, and process logic enforced centrally. Choose Azure SQL when you need full schema control, complex stored procedures, cross-database queries, very high transaction volumes, or a data warehouse. Many mature estates run both and bridge them with virtual tables or Synapse Link.

• →Dataverse = governed operational data platform bundled with logic, security, and Power Platform
• →Azure SQL = general-purpose database where you own the schema, logic, and app layer
• →Dataverse stores data across Azure SQL, Azure Storage, and Cosmos DB — it is more than one database
• →Use both: Dataverse for operational apps, SQL for analytics/warehouse, bridged via virtual tables or Synapse Link
• →Choose Dataverse when Power Platform integration and centralized rules matter more than raw SQL control

The Dataverse security model: row, column, and environment level

Dataverse security is role-based and is active only in environments that have a Dataverse database. Microsoft's documentation describes it as a 'rich security model that can adapt to many business usage scenarios,' combining business units, role-based security, row-based security, and column-based security into one stack. The model 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. A critical rule Microsoft stresses is that 'all privilege grants are accumulative with the greatest amount of access prevailing' — so broad Organization-level read cannot be narrowed later by hiding a single record.

Ownership is foundational to row-level security. Dataverse supports two ownership types, fixed at table creation and unchangeable afterward: Organization-owned (access is simply yes/no per privilege) and User/Team-owned (access tiers across Organization, Business Unit, Parent:Child BU, or the user's own records). Business units segment the organization — every database has a single root business unit, plus optional child units that act as security boundaries. Modernized 'matrix' business units let a user own and access records across multiple business units without a separate role in each.

Column-level security adds field-level granularity. When record-level control is not enough, you enable column-level security on a column (custom columns and most PII system columns), then create a Column Security Profile that grants Create, Update, and Read access for the secured columns. A user must already have record access for the profile to grant column access. Teams add another layer: owning teams can hold records (giving members direct access), while access teams share records via templates for exception-based, performant access.

• →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
• →Two ownership types, fixed at table creation: Organization-owned or User/Team-owned
• →Business units (root + child) are the security boundaries; modernized matrix units allow cross-BU ownership
• →Column-level security via Column Security Profiles (Create/Update/Read per column)
• →Privilege grants are accumulative — greatest access always prevails, so design roles carefully upfront

Dataverse API limits, throttling, and capacity planning

Dataverse enforces two distinct categories of API limits, and confusing them is a common source of production incidents. The first is service protection limits — short-burst throttling designed to stop any single user from overwhelming the shared platform. The second is entitlement (Power Platform Request) limits — daily request quotas tied to each user's license. Microsoft documents both, and they are evaluated independently.

Service protection limits are evaluated per user within a five-minute (300-second) sliding window on each web server. There are three facets: the number of requests a user sends, the combined execution time of those requests, and the number of concurrent requests. When a facet is exceeded, the Web API returns a 429 Too Many Requests error with a Retry-After header (in seconds); the SDK for .NET returns an OrganizationServiceFault with the same retry duration. Normal interactive users almost never hit these — they affect bulk-loading or portal applications behind a service principal.

Entitlement limits are different: they count CRUD operations (including share and assign) over a 24-hour period and depend on the user's license. Occasional, reasonable overages are tolerated today — users are not blocked — but administrators are notified and can assign Power Platform request capacity add-ons. Dataverse Search uses a separate API (api/search rather than api/data) with its own throttle of one request per second per user.

Capacity planning means sizing both your API throughput and your storage pools. Storage is tracked across three pools — Database (structured table data and metadata), File (attachments, images, notes), and Log (audit history and plug-in traces) — and Dataverse and Operations (F&O) database/file entitlements are now pooled together, while Log is tracked separately. The default environment includes 3 GB Database, 3 GB File, and 1 GB Log. When consumption exceeds entitlement, admins either draw from the tenant pool or link the environment to a pay-as-you-go Azure billing plan.

• →Two limit categories: service protection (5-min throttle) vs entitlement (24-hr daily quota)
• →Service protection: 6,000 requests, 20 min execution time, 52+ concurrent — per web server, per user
• →Breaches return HTTP 429 with a Retry-After header; design clients to honor it and back off
• →Dataverse Search has its own throttle: one request per second per user
• →Storage is three pools (Database, File, Log); default environment starts at 3/3/1 GB
• →Overage is managed via the tenant pool or a pay-as-you-go Azure billing plan

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. Overage is not catastrophic — you can draw from the tenant pool or attach a pay-as-you-go Azure plan — but ignore the 15% and 5% remaining warnings and you will be blocked from creating or restoring environments.

• →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
• →Storage warnings fire at 15% and 5% remaining; overage blocks environment create/restore operations

Dataverse for Teams: the free entry-level tier

Microsoft also ships Dataverse for Teams — a no-extra-cost, reduced-capability version of Dataverse built into Microsoft Teams and licensed through most Microsoft 365 plans. It is the most common way to try Dataverse without buying a Power Apps Premium license, and it is genuinely useful for lightweight internal apps. Microsoft's comparison documentation is explicit that Dataverse for Teams 'focuses on one environment per team' with roughly 2 GB of capacity (about 1 million rows), simplified security based on team membership (owners, members, guests), and a single business unit per environment.

The capability gap is the real story. Dataverse for Teams has no API access, no plug-ins, no Power Apps component framework, no model-driven apps (canvas apps only), no Dataverse search, no mobile offline, and no field-level or hierarchical security. Most of the standard tables that ship with a full Dataverse environment (account, contact, lead) are not present. The trade-off is capacity and depth: if you need full role-based security, business units, API access, plug-ins, or Dataverse search, you must upgrade the Teams environment to full Dataverse. That upgrade is one-way and brings the environment under normal Dataverse licensing — so it pays to decide early whether a Teams-scoped app will outgrow the entry tier.

• →Dataverse for Teams is the free, reduced-capability version included with most M365 plans
• →Roughly 2 GB (~1 million rows), one environment per team, simplified membership-based security
• →No API access, plug-ins, model-driven apps, Dataverse search, or mobile offline
• →Upgrade to full Dataverse is one-way and triggers normal Dataverse licensing

Common Dataverse patterns for ERP integration

Most SMEs do not start with a blank Dataverse — they arrive with an ERP and want to connect it. The integration pattern you choose depends on which ERP you run and how real-time the data needs to be. The three dominant patterns are native storage (CE apps), dual-write (F&O apps), and connector/virtual-table bridging (Business Central and third-party ERPs).

For Dynamics 365 customer-engagement apps, there is no integration to build — the data already lives in Dataverse. A model-driven app or flow reads and writes the same accounts and contacts that Sales or Customer Service use. This is the lowest-friction scenario and the one where Dataverse-centric architecture pays off most.

For Finance and Operations (Finance, Supply Chain Management, Commerce), Microsoft's dual-write framework provides near-real-time bidirectional sync between the F&O database and Dataverse. Dual-write is powerful but needs careful setup and tuning — table maps must be enabled and validated, and initial bootstrap synchronization can take time. The Data Integrator is the older, lighter alternative for one-way or scheduled flows.

For Business Central and third-party ERPs, the standard approach is connector-based: Power Automate flows or the Business Central connector surface BC data in Dataverse, or virtual tables present external data as if it were native Dataverse without copying it in. Virtual tables are attractive when you want a unified app experience over data that should remain in the ERP's own database. The trade-off is that virtual tables do not support all Dataverse features (for example, some offline and audit scenarios), so they suit read-heavy or extension scenarios better than high-volume transactional writes.

• →CE apps need no integration — data is already native to Dataverse
• →F&O apps use dual-write for near-real-time bidirectional sync (needs table-map tuning)
• →Business Central connects via the BC connector, Power Automate, or virtual tables
• →Virtual tables surface external data as native Dataverse without copying it in (read-heavy use)
• →Synapse Link exports to Azure Data Lake for analytics and reporting without touching transactional load

Migrating data into (and out of) Dataverse

Moving data into Dataverse is a well-trodden path with tooling for every scale. For one-time or infrequent imports, Microsoft supports direct Excel and CSV import into a table — fine for small reference data. For transforming data from many sources during import, Power Query is the standard tool, reused from Excel and Power BI, and it handles cleansing, type conversion, and column mapping before the rows land in Dataverse.

For scheduled, recurring synchronization from another application, the Data Integrator and dual-write handle CE/F&O scenarios, while Power Automate flows or custom connectors handle third-party systems. The key design decision is whether to copy data in (physical tables, full Dataverse features, costs storage) or surface it virtually (virtual tables, no duplication, limited feature set). Copy-in suits transactional operational data; virtual tables suit read-heavy extension over a system of record that must stay elsewhere.

When migrating out of a legacy CRM or ERP into Dataverse, the recommended sequence is: map source fields to standard Dataverse tables first (account, contact, lead), create custom tables only for data that has no standard home, cleanse and de-duplicate before import, and use batched loads that respect service protection API limits (6,000 requests / 5-min window). For very large migrations, use Synapse Link to stage data in Azure Data Lake and the Data Factory or KingswaySoft tooling to orchestrate high-throughput loads with retry-on-429 handling.

A migration pitfall worth naming: the Owning Business Unit column. If you sync data between environments and the target does not have the same business unit values, the job fails with a foreign-key constraint violation. Either remove that column from the source schema or align business-unit values across environments before migrating.

• →One-time imports: Excel/CSV for small reference data; Power Query for multi-source transform-and-load
• →Scheduled sync: Data Integrator or dual-write for Microsoft apps; Power Automate / connectors for others
• →Decide copy-in (full features, costs storage) vs virtual tables (no duplication, limited features)
• →Map to standard tables first; create custom tables only where no standard fit exists
• →Batch large loads to respect the 6,000-request / 5-min service protection limit; use Synapse Link + Data Factory for scale

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

Frequently asked questions