Dataverse table

What is a Dataverse table?

A Dataverse table describes a kind of business object whose records you store or display, such as a customer, a case, an inspection or an invoice. It is the table construct inside Microsoft Dataverse, and it was called an entity before Microsoft updated the terminology in late 2020.

A table is more than a set of fields. It bundles columns, relationships, ownership, privileges, forms, views, business rules and other metadata that apps and automations rely on.

Every table has a unique logical name, and every row has a GUID as its primary key. A separate primary name column supplies the readable text that users see when the record shows up in a lookup.

Standard and custom tables

Dataverse comes with standard tables such as Account and Contact, and Dynamics 365 apps add more tables and behaviour. Reusing them can hand you working integration and features you would otherwise build yourself.

A custom table is created for your own domain and takes the publisher prefix of its solution. Give it a singular, stable business name rather than a temporary screen or project name.

Before you create one, check whether an existing table really carries the same meaning and lifecycle. Reusing a technically similar table for a different concept makes relationships and reporting confusing later.

Ownership

Ownership is set when the table is created and cannot be changed afterwards, so it is worth getting right early.

A user- or team-owned table has an owner per record. Dataverse can then derive access from security roles, business units, teams and sharing, so different people see different rows of the same table.

An organization-owned table has no per-record owner. Access is granted at the organisation level, which suits reference or configuration data that means the same thing for everyone.

A customer case model

Suppose an organisation builds tables for Customer, Case, Document and Assessment. One customer can have several cases; one case can have several documents and assessments.

Case is user-owned, because teams should only see their own workload. A Case type table is organization-owned, because the same reference values apply to everyone.

Forms and views draw on the same metadata, so a model-driven app can offer a case form, related documents and views per status without anyone building a separate data layer.

Keys and duplicates

The GUID identifies a record internally. For integration, an alternate key can mark one or more columns as a unique business key, such as an external customer number.

An alternate key helps with upsert and stops duplicate key values from slipping in. It does not replace broader duplicate detection when a match has to be inferred from several uncertain attributes.

Be careful using changeable data such as an email address as a key. A stable source id is usually the safer choice.

Special table types

Activity tables support timeline and activity behaviour for things like appointments and tasks. Elastic tables, backed by Azure Cosmos DB, target very large datasets running into tens of millions of rows and behave differently from standard tables.

Virtual tables show external data as Dataverse records without copying it in by default. Which operations are available depends on the data provider and the source.

Pick a type on functional and operational grounds. Not every Dataverse feature supports every table type in the same way.

What to watch out for with Dataverse tables

Place custom tables in a solution and move schema changes through development, test and production. Removing a column or changing a data type can affect stored data and dependent components.

Document meaning, source, owner and relationships. Test security with ordinary user accounts rather than an administrator, and revalidate integrations on every schema change.

A good table model reflects durable business concepts. Forms and apps can change without the same information having to be rehoused in a new schema each time.