Dataverse tables hold business data as rows of records with typed columns, linked to each other through relationships. Three settings on each table shape every app built on it: its ownership type, its column security and the way its relationships pass changes to linked rows. The ownership type, which decides whether access can differ from row to row, can’t be changed once the table exists.
Table of Contents
What is a Dataverse table?
A Dataverse table is a set of rows, each one a record, with columns that hold a set type of data such as text, currency or a choice from a list. Each row takes its display name from the primary name column, lookup columns tie it to rows in other tables and settings on the table set the limits on who can reach it.
The table holds more than its data:
- Each column has a data type, such as text, whole number, currency, choice or lookup.
- The primary name column is the value a lookup shows when another table links to a row.
- A lookup column creates a relationship, letting one customer row sit above many order rows.
- Part of the security model lives on the table itself: its ownership type and any column security on its columns.
- Auditing is configured for each table and column, once it is on for the environment.
Our Power Apps guide covers where Dataverse fits against SharePoint lists and SQL Server as the home for an app’s data.
What are the types of tables in Dataverse?
Microsoft’s types of tables page lists four: standard, activity, virtual and elastic. A table you create yourself is called a custom table. When you create one, you set its table type. Standard is the type to pick for most tables. Virtual and elastic tables cover data that lives outside Dataverse or grows past tens of millions of rows.
The table below compares the four types side by side.
| Table type | What it holds | Ownership | Watch for |
|---|---|---|---|
| Standard | Common business records such as Account and Contact | Set per table | Most can be customised |
| Activity | Records with a subject, start time, due date and duration | User or team only | Can’t be organisation owned |
| Virtual | Data read from an outside source at runtime | Organisation | No auditing and no row-level security |
| Elastic | Very large datasets beyond tens of millions of rows | Record ownership supported | No multi-record transactions or cascading actions |
A virtual table shows data from an outside source such as SQL Server or SharePoint at runtime, without copying it into Dataverse. Two of the virtual table limits matter most here: virtual tables are organisation owned and support neither Dataverse’s row-level security nor auditing.
Elastic tables run on Azure Cosmos DB and are built to take in tens of millions of rows. In exchange they give up multi-record transactions, many-to-many relationships to standard tables and cascading actions.
Which ownership should a table have?
A custom table is owned by a user or team or by the organisation. Microsoft’s ownership-based security page says the ownership type is chosen when the table is created and can’t be changed later. A third option, filtered ownership, grants access by the value of a column and is in preview.
User or team ownership is what makes access row by row possible: on those tables a security role can limit people to the rows they or their part of the business own. On an organisation-owned table a privilege applies to every row or to none of them.
If different people might ever need different rows, give the table user or team ownership from the start. Changing it later means creating a new table and moving the data across before repointing whatever used the old one. Our guide to model-driven app security roles covers how roles and access levels are then set up.
How do relationships work between Dataverse tables?
Dataverse has two kinds of relationship: one-to-many and many-to-many. A lookup column on the child table creates a one-to-many, such as one customer with many orders. Many-to-one is the same relationship seen from the child’s side. Every one-to-many also carries a behaviour that decides what happens to the child rows when the parent changes.
A many-to-many relationship, like the one between staff and the sites they work at, has no behaviours to set and links rows through a hidden relationship table that can’t hold custom columns. When the link needs data of its own, such as each person’s role at each site, the pattern is a custom table with two many-to-one relationships. Microsoft’s complex relationships guidance keeps it for exactly that case. Switching between the two approaches later means migrating the data.
A relationship’s behaviour sets what it passes from a parent row to its children when someone assigns, shares, unshares, deletes or merges the parent or moves a child to a new parent. Parental behaviour passes every one of those actions except merge on to the child rows, down to deleting all of them when the parent is deleted. Referential behaviour doesn’t pass actions on to the child rows. When the parent is deleted, its Remove Link version clears the lookup on those rows and its Restrict Delete version blocks the deletion while child rows are linked to it. Custom behaviour sets each action separately.
How does security fit into the table design?
What a security role can reach depends on a table’s ownership type, column security and relationship behaviour. Ownership decides whether a role can separate one person’s rows from another’s. Column security hides or locks individual columns. Relationship behaviour decides whether access to a parent row, through its owner or a share, carries down to its child rows.
Column security is organisation-wide and applies to all data access requests. Four details catch builds out:
- System administrators see every column: column security doesn’t apply to them.
- Some columns can’t be secured, lookup and primary name columns among them.
- A calculated or prompt column that uses a secured column can show the secured column’s data to people without access unless the calculated or prompt column is secured too.
- Column security doesn’t grant access to a record. A person has to be able to reach the record first.
Anyone who can see a record holding a lookup can see the primary name of the row it points to, even without permission to open that row. Keep sensitive information out of primary name columns. An incident named after the person involved shows that name wherever it is looked up.
When a relationship’s assign action is set to Cascade All, reassigning the parent row hands its child rows to the new owner and, by default, the new owner’s business unit. Cascade Active and Cascade User Owned do the same for some of the child rows. Under parental behaviour the parent row’s owner also inherits access to its child rows. Check every cascading setting, reparent included, before a table of sensitive notes hangs off a parent.
The Office of the Australian Information Commissioner’s Australian Community Attitudes to Privacy Survey found 77% of Australians whose data was involved in a breach experienced at least one form of harm. The OAIC’s notifiable data breach statistics put 716 of the 1,205 notifications in 2025 down to malicious or criminal activity. Table design doesn’t stop an attack. We treat “Dataverse has row-level security” as true only of a table built to be owned by users or teams.
What does this look like on a real build?
A Perth aged care provider we work with runs a model-driven app on Dataverse that holds between 10,000 and 100,000 records. Access is set through business units, teams, record ownership and column security working together. The provider needed Dataverse rather than SharePoint lists or SQL Server for record-level security, related tables, volume and audit history with business rules.
Column security covers the fields a person shouldn’t see on a row they can otherwise open. Audit history is a table decision too: once auditing is on for the environment, it is configured for each table and column it covers.
Table design is where our Power Apps development on Dataverse starts.
Should a SharePoint list move into Dataverse tables, or just connect?
Move a SharePoint list into Dataverse tables when the data needs more than a list’s permissions and structure give it comfortably: access by role down to the row, several related tables or room to grow. Keep the list and connect to it when it is simple and people mostly work with it in SharePoint.
Microsoft’s Lists and Dataverse comparison sets out the security difference. Lists offers owners, members, visitors, designers and approvers roles with customisable permissions. For Dataverse the comparison names security roles, business units, auditing, customer-managed keys, hierarchical security and column-level security.
These are the signals we look for:
- Different people need to see different rows.
- Several lists point at each other through lookup columns and keeping them consistent takes manual work.
- An app on the list is hitting delegation limits as the data grows. Our Power Apps guide explains those under Power Apps limitations.
When none of those apply, connecting is enough. A Power App can use the list directly, or a virtual table can show it inside Dataverse without copying it. The virtual table route has a catch: every user reads the list through one connection’s credentials. Dataverse security roles and the shared connection, not each person’s SharePoint permissions, decide who can open the virtual table. Everyone who can open it sees the same rows.
Our guide to how Power Apps is licensed explains what each user needs once an app’s data moves into Dataverse or shows there as a virtual table.
Frequently asked questions
How many rows can a Dataverse table have?
Microsoft documents no row limit for a Dataverse table. Rows count against the storage capacity your licences entitle you to. For datasets in excess of tens of millions of rows, Microsoft points to elastic tables.
Is Dataverse a relational database?
Dataverse is relational. Its tables link to each other through one-to-many and many-to-many relationships. In a one-to-many, a lookup column on the child row points at its parent. Microsoft’s comparison of Lists and Dataverse describes Dataverse data as relational, a type it doesn’t list for Lists.
Can you change a table’s ownership after it’s created?
No. The ownership type of a custom table is chosen when it is created and can’t be changed afterwards. A table that needs a different ownership type has to be replaced: create a new table and move the data across, then repoint whatever used the old table before deleting it. Choose user or team ownership for any table where different people may need different rows.
What is the difference between a standard table and a custom table?
In the Power Apps Tables list, a standard table is one included with Power Apps or a Dynamics 365 app, such as Account, Contact or User. A custom table is one you or another app maker creates. Most standard tables can be customised. The standard table type is a separate setting: it is the type to pick for most custom tables.
How do you view Dataverse tables?
Sign in to Power Apps and select Tables on the left navigation pane. If Tables isn’t in the side panel, it sits under More. The Recommended view shows only the standard tables, Custom shows the tables you and other app makers have created and All shows every table in the environment.
How do you create a Dataverse table?
Select New table from Tables in Power Apps. You can create a new table, set advanced properties, create one from external data or create a virtual table. You need an environment with Dataverse and the System Customizer or System Administrator role. Choose the ownership type before you save. It can’t be changed later.
Get the table design right before the first screen
A Dataverse table’s limits on who can reach which rows and fields are set before anyone opens a security role. Settle ownership, column security and relationship behaviour for each table first. Start with ownership, the one setting here that can’t be changed later.
If you are moving SharePoint lists into Dataverse or starting a model-driven app, OfficePro Consulting can review the data model with you before anything is built. Start with a free initial conversation about your data model.
