Dataverse security roles and column security
Dataverse security is layered, and every layer appears on the exam. Roles decide what a user can do, business units and ownership decide which rows, and column security decides which columns.
Business units and roles
Every environment has a root business unit, and you can add children. A user belongs to exactly one business unit. A security role is a set of privileges (Create, Read, Write, Delete, Append, Append To, Assign, Share) on each table, with an access level:
| Level | Reaches |
|---|---|
| None | Nothing |
| User | Rows the user owns (or that are shared) |
| Business Unit | Rows in the user’s own business unit |
| Parent: Child Business Units | Own unit and all below |
| Organization | All rows |
A user gets the union of all roles, so the most permissive access wins. Roles can be given directly or through a team.
Teams
- Owner team: can own rows and hold roles.
- Access team: has no roles; used to share individual rows.
- Microsoft Entra ID group team: membership comes from a Microsoft Entra security or Microsoft 365 group. Entra ID was formerly called Azure Active Directory.
Common built-in roles
| Role | Purpose |
|---|---|
| System Administrator | Full control of the environment |
| System Customizer | Customize all components, limited data access |
| Environment Maker | Create apps, flows and connections |
| Basic User | Read and write own data in common tables |
Maker rights and data access are separate. A maker needs Environment Maker plus a role with table privileges.
Column-level security
Mark a column as Enable column security, then create a column security profile with Read, Update and Create permissions, and add users or teams. Users outside any profile see the value as masked. Only some columns can be secured; the primary name and system columns cannot.
Sharing and hierarchy
- Share gives an individual user or team access to one row.
- Manager hierarchy and position hierarchy let managers see rows of reports, up to a configured depth.
Exam traps
- Hiding a column on a form is not security. Use column-level security.
- Roles accumulate; you cannot remove access by adding a restrictive role.
- Business Unit access does not include child units. That needs Parent: Child.
- Environment Maker does not grant access to data in tables.
- Access teams share rows only; they cannot carry security roles.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. A user must build canvas apps that use Dataverse data, with no more permission than needed. Which built-in role fits?
Show answer
Answer: B.Environment Maker lets a user create resources in the environment. Users still need a role that grants access to the table data.
2. Only the HR team may see the Salary column on the Employee table. What do you use?
Show answer
Answer: B.Column-level security protects the data itself. Hiding on a form or view does not stop access from other forms, Advanced Find or the API.
3. A manager must see rows owned by direct reports, but not other rows. What do you configure?
Show answer
Answer: B.Hierarchy security (manager or position) gives managers access to rows of people below them.
4. A role gives Read at Business Unit level on Account. Which users can read an account owned by a user in a child business unit?
Show answer
Answer: A.Business Unit access covers only rows in the user's own business unit, so users in the parent unit cannot read it. The Parent-Child Business Units level would add child units.