Dataverse security role

What is a Dataverse security role?

A Dataverse security role is a set of privileges that decides which apps, tables and platform features a user or team may use inside one Microsoft Dataverse environment. It is how Dataverse applies role-based access control (RBAC) to business data.

For a table, a role pairs an operation, such as Read, Create, Write, Delete, Append, Append To, Assign or Share, with an access level. That combination lets the same operation apply only to a user's own records, or more widely across the organisation.

A user needs at least one suitable role to touch Dataverse data at all. A Power Platform tenant admin role does not by itself grant access to the data inside every environment.

Privileges and access levels

A privilege names the allowed action. Read opens a record to view it, Write changes it, and Append and Append To govern how records get linked to one another.

The access level sets the reach. In the maker interface the levels read as User, Business Unit, Parent: Child Business Units and Organization, plus None; the security model calls the same levels Basic, Local, Deep, Global and None. User (Basic) covers records you own or that are shared with you, and Organization (Global) covers every record in the environment. Deep and Local only differ once you have a hierarchy of business units.

Not every privilege uses the same depths. Organization-owned tables have no per-record owner, so their privileges are effectively an on/off switch at Organization or None.

Roles combine cumulatively

A user can hold several security roles, and the rights add up. A more restrictive role does not subtract a broader privilege granted by another role.

This makes composite jobs possible, for example a base role plus a temporary approver role. It also means access troubleshooting has to look at every role, both assigned directly and inherited through teams.

There is no general deny role that claws back a granted right. To reduce access, remove or narrow the role that hands out the broad privilege.

Business units, teams and ownership

Security roles are tied to a business unit. User- and team-owned records have an owner, and access levels use that ownership together with the business unit structure to work out reach.

Owner teams can own records and hold roles. Access teams grant access to specific records through templates without owning them. Microsoft Entra group teams can tie group membership to Dataverse access, so it is worth checking group management and the team's own roles when you use them.

An example for case management

Case handlers may read and edit cases owned by their own team. A quality role may read cases across the whole organisation but not delete them.

A finance team gets access to payment data through an additional role and, where needed, column-level security. The app shows only the relevant pages, but the server-side rights remain the real boundary.

An external auditor gets a temporary read-only role in a walled-off environment or business unit, with the end date and owner of that access recorded.

How this compares to other access controls

Row Level Security (RLS) in a Power BI semantic model filters which rows a report reader sees; a Dataverse security role controls what a user can do to records in the source database itself. They solve different problems and are often both in play in the same solution.

Dataverse roles are firmly role-based. They decide access from who you are and which team and business unit you sit in, rather than evaluating live attributes of the record at query time the way attribute-based access control (ABAC) does. Column-level security and access teams add finer grain on top when a role alone is too coarse.

What to watch out for with security roles

Start from task-focused custom roles rather than broad copies of System Administrator, and grant least privilege: only the table operations and access levels a job actually needs. Treat System Administrator as a powerful data right, not harmless support access.

Version custom roles in solutions and test with accounts that hold only the intended roles, since a test run by an administrator masks missing privileges. Review direct assignments, team roles and temporary access on a schedule, and record the owner and purpose of each custom role so stale rights can be removed.