Dataverse Security Model: Roles, Teams, and Business Units Explained

Security in Dataverse is powerful but complex. Getting it right from the start saves hours of debugging access issues later.

The Four Pillars of Dataverse Security

1. Business Units

Business units represent your organization's structure. Every user belongs to exactly one business unit.

• Root business unit — Created automatically, cannot be deleted
• Child business units — Mirror your org structure (departments, regions)
• Security inheritance flows downward — parent BU admins can see child BU data

2. Security Roles

Security roles define what a user can do with each table. Each permission has a scope (depth):

3. Teams

Teams group users for shared security:

• Owner teams — Can own records, useful for shared mailboxes or queues
• Access teams — Grant access to specific records dynamically
• Azure AD group teams — Sync with Azure AD security groups automatically

4. Field-Level Security

Restrict access to specific columns:

• Create a Field Security Profile
• Add columns to the profile
• Set Read, Create, Update permissions
• Assign users or teams to the profile

Common Patterns

Pattern 1: Department Isolation

Each department is a business unit. Users see only their department data. Managers see their department plus sub-departments.

Pattern 2: Account-Based Access

Sales reps own their accounts. The sales manager role grants BU-level access to see all team accounts.

Pattern 3: Sensitive Data Protection

Salary and SSN columns are protected with field-level security. Only HR team members have the profile assigned.

Debugging Security Issues

1. Check the user's security roles and their scopes
2. Verify the user's business unit assignment
3. Look for team memberships that might grant additional access
4. Check field security profiles for column-level restrictions
5. Use the Access Checker tool in the admin center