5.4 Configuring Dataverse Security

Security Roles: Privileges × Access Levels

Dataverse authorization starts with security roles. A role is a matrix: for every table it grants a set of privileges, each at an access level (depth). Users accumulate the most permissive combination across all the roles they hold — directly or through team membership.

The eight record privileges:

• Create, Read, Write, Delete — the basic data operations
• Append — allows other records to be associated to this record (this record is the parent of the association)
• Append To — allows this record to be attached to another record (this record is the child of the association)
• Assign — change the record's owner
• Share — grant record access to another user or team while keeping your own access

The four access levels, from narrowest to broadest:

Business units

Every Dataverse environment has exactly one root business unit, and child business units can model divisions (for example, Sales → East, West). Each user belongs to one business unit, and security roles created in a parent business unit are inherited by — visible in — its child business units. The business unit structure is what gives the Local and Deep access levels their meaning, and it is why the question 'why does this user see some rows but not others?' usually traces back to a Basic or Local grant combined with ownership, sharing, or team membership.

Teams and Sharing

Owner teams own records: they are assigned security roles, records can be assigned to them, and every member receives the team's access. Use owner teams for durable groups such as East Region Sales.

Access teams are lightweight and auto-managed (often created per record): they cannot own records and hold no security roles — members simply receive whatever privileges were shared with the team. Use access teams for ad-hoc, record-by-record collaboration at scale.

Sharing grants specific privileges (Read, Write, Delete, Append, Assign, Share) on one record to a user or team without changing ownership. A user with only Basic-level Read can still open a colleague's record if it was shared with them. To diagnose effective access, use Check Access on the record — it lists exactly which privileges a user has and why (role, team, share, or hierarchy).

Column-Level Security

Sometimes row-level control is not enough: everyone can read the Employee row, but only HR may see Salary. Dataverse handles this with column (field) security:

1. Mark the column as secured (the column property Enable column security).
2. Create field security profiles that grant Create, Read, and Update on the secured column.
3. Assign users or teams to each profile.

A user in multiple profiles gets the most permissive combination; users in no profile see the column as blank or locked. System Administrators bypass column security entirely, and some system columns cannot be secured. Column security is honored broadly — forms, views, searches, exports, and API access all respect it.

Hierarchy Security

Hierarchy security layers managerial visibility on top of roles. It is configured in the Power Platform admin center (environment → Settings → Users + permissions → Hierarchy security) and comes in two models:

• Manager hierarchy — follows the Manager field on each user record; a manager gains access to records owned by direct reports, with a depth setting controlling how many reporting levels down the access extends. Best fit for the classic org chart.
• Position hierarchy — builds an explicit position tree independent of the manager chain, useful when reporting lines do not match data-visibility needs.

Hierarchy security adds access; it never removes what roles grant, and the manager still needs at least Basic-level privileges on the table for the hierarchy to matter.

Minimum Privileges: Run vs Customize

• To run a model-driven app, a user needs the app shared with them plus a security role granting at least Basic privileges on the tables the app uses (Read at minimum, plus Create, Write, or Append as the app requires). The built-in App Opener role captures the bare minimum needed to open apps — copy it and add table privileges rather than over-granting.
• To customize — edit tables, forms, views, or apps — assign System Customizer (or System Administrator). System Customizer holds organization-level rights over customization metadata; never hand it to end users just to fix a 'cannot see rows' complaint.

Exam Traps

• Append / Append To pair: associating two records needs Append on the parent side and Append To on the child side. To add an Order Line to an Order, the user needs Append on Order and Append To on Order Line. Missing either half produces the classic 'insufficient permissions' error even when Create and Write look fine.
• 'Sees some rows but not others': check (1) the access level (Basic vs Local vs Global), (2) ownership, (3) sharing and team membership, (4) hierarchy security, and (5) column security when values are missing rather than rows.
• Assign vs Share: Assign changes ownership (a record has exactly one owner); Share grants additional access without changing the owner.