Dataverse security roles and column security

Security in Dataverse is layered. The exam asks which layer to use for a given requirement, so learn what each layer controls.

Security roles and access levels

A security role is a set of privileges on tables: Create, Read, Write, Delete, Append, Append To, Assign, Share. Each privilege has an access level:

Level	Scope
None	No access
User	Rows the user owns (or that are shared with them)
Business Unit	Rows owned by anyone in the user’s business unit
Parent: Child Business Unit	Own unit plus child units
Organization	Everything

“Managers see all opportunities in their organization or unit” is solved by raising the Read level, not by changing the app.

Users and teams get roles. Team membership is the easiest way to manage groups, including Microsoft Entra ID group teams. Business units form a hierarchy and own the data scope.

Column-level security

Roles work on whole tables. To hide a single column, mark it as secured (Enable column security) and create a column security profile. Add users or teams and set Read, Update and Create for each secured column.

Because security is enforced by Dataverse, the column is hidden in forms, views, advanced find and reports. A business rule that hides a field only changes the form and does not protect the data.

Row sharing and ownership

Tables can be user or team owned or organization owned. Only user or team owned tables are scoped by business unit. You can share an individual row with a user or team when role scope is not enough, and use hierarchy security for manager access across reporting lines.

Views and apps

Personal views belong to a user. System (public) views are visible to all users with read access. To limit a view, assign it to specific security roles. Model-driven apps also use roles to decide which apps, site map items and forms a user can open.

Environment access

Environment-level access is separate. A user needs a license and a role in the environment, which is managed in the Power Platform admin center. Data loss prevention (DLP) policies control which connectors can be combined.

Exam traps

• A business rule or hidden form field is not security. Use column-level security for protection.
• User level is not owner-only forever: shared rows are also visible.
• Business unit access does not include child units. For that use Parent: Child.
• Deleting a column to hide it destroys data. Use a secured column.

Practice questions

Choose an answer, then review the explanation to check your understanding.

1. Sales managers must see all opportunities of their own organization, including those owned by other users in the same business unit. What do you configure?

1. A.A security role with Business Unit read access on the Opportunity table
2. B.A security role with User read access
3. C.A business rule
4. D.A canvas app filter

Show answer

Answer: A.The Business Unit access level gives read on all rows owned by users in that business unit.

2. Only the address1 columns of Account must be visible to ordinary users, including in views and advanced filters. What do you use?

1. A.Business rules that hide columns
2. B.Column-level security with a field security profile
3. C.Delete the other columns
4. D.Turn off Searchable

Show answer

Answer: B.Column-level security restricts read, create and update on secured columns, so they are hidden everywhere, including views and filters.

3. A public view must be available only to managers. What is the best approach?

1. A.Remove the view from the navigation
2. B.Assign the view to the manager security role
3. C.Configure the Quick find view
4. D.Delete the view for other users

Show answer

Answer: B.A public view can be shared or assigned to security roles so only those users see it.

4. Which access level gives a user access to rows across the whole environment?

1. A.User
2. B.Business Unit
3. C.Parent - Child Business Unit
4. D.Organization

Show answer

Answer: D.Organization is the widest level and ignores business unit boundaries.