Dataverse data model fundamentals
The Dataverse data model — tables, columns, relationships, choices, security roles, and how it sits under Dynamics 365 and the Power Platform.
Microsoft Dataverse is the shared, managed data platform that sits underneath Dynamics 365's CRM-side apps and the Power Platform. It looks superficially like a SQL database, but it's a higher-level model — with built-in security, audit, business rules, and APIs — designed to be the data layer of an application rather than just a store.
Tables. A table holds rows (records) of one logical entity — Account, Contact, Opportunity, plus tables you create. Tables have standard ones (Microsoft-provided), custom ones (you create), and virtual ones (data sourced from outside Dataverse but exposed as if local). Every table has a unique name, a display name, and a primary key (GUID by default).
Columns. Columns are typed: text, number, decimal, date, choice (option set), lookup (foreign key), file, image, customer (polymorphic to Account or Contact), and several others. Required-ness is enforced by the platform.
Relationships. 1:N, N:1, N:N, and self-referential relationships are all first-class. The platform also supports polymorphic lookups (a Customer column on Opportunity that can point to either Account or Contact). Relationships drive cascade behaviour: deleting a parent can cascade, restrict, or remove links to children.
Choices and choice sets. Picklists are modelled as choices (local to one column) or choice sets (reusable across columns and apps). Global choice sets are how you avoid duplicated Yes/No/Maybe lists across the schema.
Calculated and rollup columns. Server-side computed columns: calculated (formula evaluated at read time) and rollup (aggregate across related rows, refreshed on a schedule).
Business rules. No-code field-level logic — set value, lock field, validate — defined per form. Run on the client and the server.
Security. Role-based security with security roles that grant table-level privileges (create, read, write, delete, append, append-to, assign, share). Business units scope rows; teams group users for shared ownership; field-level security restricts individual columns.
Auditing and history. Audit is a setting per table and per column; every change is recorded, viewable per record.
APIs. Dataverse exposes everything through OData v4 and a SOAP variant, with first-class SDKs for .NET, JavaScript, and Python.
Storage tiers. Database (default, fast, expensive), file (attachments, cheaper), log (audit, cheapest). Managing tier usage is the main cost lever for Dataverse capacity.
Related guides
- Dataverse data import templatesHow to bulk-import data into Dataverse using import templates — the wizard, CSV/Excel formats, lookups by name, duplicate detection, and the gotchas of large imports.
- The Dataverse security modelRoles, business units, teams, row sharing, and field-level security in Dataverse — the layers that protect data in Dynamics 365 CRM and Power Apps.
- App designer for model-driven appsHow to build a model-driven Power App — site map, tables, forms, views, business process flows, dashboards, and the app-experience layer.
- Async jobs in DataverseHow Dataverse runs background work — system jobs, async plug-ins, workflow runs, and how to monitor, troubleshoot, and prevent the async backlog from getting out of hand.
- Bulk delete jobs in DataverseHow Dataverse's bulk delete handles mass record cleanup — scheduling, filters, retention policies, and the operational discipline around storage management.