Dataverse Row-Level Security: A Quick Primer

Introduction

Row-level security in Dataverse determines who can see and modify which records. It's built on business units, security roles, and ownership — and getting it wrong leads to "I can't see my records" support tickets.

This primer covers the essentials every CE consultant should know.

The Three Layers

Dataverse security works in layers:

1. Organization — Access to the environment itself
2. Entity — Create/Read/Write/Delete/Append/Append To privileges on tables
3. Row — Which specific rows a user can access

Row-level security is that third layer. Even with Read access on an entity, users only see rows they're allowed to see.

Business Units

Business units (BUs) are the foundation of row-level security. Every user belongs to exactly one business unit.

• Root BU — Created automatically; typically contains admin users
• Child BUs — Represent divisions, regions, or teams
• Records can be owned by a user or team, or shared with specific users/teams

Key point: a user in BU A cannot see records owned by users in BU B unless those records are explicitly shared or the security role grants access across BUs.

Security Role Scope

When configuring a security role, each privilege has a scope:

| Scope | Meaning | |-------|---------| | User | Only records the user owns | | Business Unit | Records owned by users in the same BU | | Business Unit and Child | Same BU + all child BUs | | Organization | All records in the environment |

For most entities, Business Unit is the default. Use User when data must be strictly private (e.g., personal tasks). Use Organization sparingly — typically for reference data or admin-only entities.

Ownership Matters

• User-owned — Record belongs to a user; row access follows that user's BU and role
• Organization-owned — Record belongs to the org; anyone with entity access can see it (no row-level filtering)

Organization-owned is useful for shared lookup data. User-owned (or team-owned) is the norm for transactional data.

Sharing and Teams

When built-in scope isn't enough, use sharing:

1. Share — Grant specific users/teams Read, Write, Delete, Assign, or Share on a record
2. Teams — Create a team, add users, assign records to the team so all members have access
3. Access teams — Dynamic membership; users get access when added to the team

Sharing is manual and doesn't scale for thousands of records. Prefer security roles and BU structure when possible.

Common Pitfalls

1. Assuming "Organization" scope for everything — Leads to over-permissive access
2. Mixing BUs inconsistently — Users in wrong BUs can't see their data
3. Forgetting hierarchical security — Manager hierarchy can grant access to subordinates' records if configured
4. Custom entities with wrong ownership — Default is user-owned; change to org-owned only when appropriate

Quick Checklist

• [ ] Map your BUs to real org structure
• [ ] Assign users to the correct BU
• [ ] Use User or Business Unit scope for sensitive data
• [ ] Use Organization scope only for reference/lookup data
• [ ] Document sharing rules for edge cases

Summary

Row-level security in Dataverse is built on business units, security role scopes, and ownership. Design your BU structure and roles early — retrofitting security is painful. When in doubt, start restrictive and open up as needed.