Security

Introduction

Dataverse security is additive, layered runtime evaluation model. The layer constitutes of:

1. Identity
2. Environment Access
3. Business Units
4. Security Roles
5. Team Membership
6. Record Ownership
7. Record Sharing
8. Access Teams
9. Field-level sharing
10. Hierarchy Security

It is not:

• A simple RBAC system
• Instantly predictable without modelling
• UI-only
• enforced at single layer

Why Dataverse Security Exists

Dataverse security is designed for enterprise CRM scenarios and exists to:

• Enforce least privilege
• Support complex organization models
• Enable record level collabrations
• Scale across department and geographies

Core Concepts

1. High-Level Security Evaluation Flow

Request(UI/API/Flow/Plugin)
        |
Identity Authenticated (Entra ID)
        |
Environment Access Check
        |
Security Role Privileges
        |
Business Unit Scope
        |
Ownership/Team Ownership
        |
Access Team Membership
        |
Field Level Security
        |
Allow or Deny

2. Business Units

Business unit should be used for structural seperation not collabration.

What Business Units Do

• Define data visibility boundaries
• Scope security role privileges
• Influence reporting and ownership

They do not:

• Grant permission by themselves
• Replace teams

Common BU Failure pattern

Single BU
  |- Hundreds of roles
      |- Excessive sharing
          |- Performance degradation

3. Security Roles

   What Roles Define

   
   Security roles define:
   • CRUD privileges
   • Privilege depth (User/BU/Parent-Child/Org)
   • Entry-level access

Roles do not:

• Grant access without records
• Override BU boundaries

Role Explosion Anti-Pattern

• One role per scenario
• Minor variations duplicated
• Hard to maintain

Better Pattern

• Base roles + additive roles

4. Ownership Model

   User-Owned Records

   • Default for transactional data
   • Subject to BU and role scope
   • Requires sharing for collabrations

   Team-Owned Records

   • Owned by Owner Teams
   • Access governed by team roles
   • Useful for queues, shared workload
5. Teams in Dataverse Dataverse supports two fundamentally different team types
6. Owner Teams

What they are

• Can own records
• Can have security roles
• Behave like users for ownership

Use When

• Shared ownership is required
• Records belong to a group, not a person

Risks

• Overuse leads to ownership ambiguity

2. Access Teams

They exists to solve one problem:

• Temporary, record-level collabration without sharing explosion

What they are:

• Record-specific access control
• No ownership
• No security roles
• Access granted via team templates

6. How Access Team Works?

Record
  |- Access Team Template
      |- User A (Read/Write)
      |- User B (Read)
      |- User C (Append)

• Teams are created dynamically per record.
• Membership controls access
• Security role still required at base level

What Access Teams Can and Cannot Do

Good vs Bad Use of Access Teams

1. Good Use
   • Case collabration
   • Opportunity deal teams
   • Temporary reviewers
   • Approval participants
2. Bad Use

• Permanent access control
• Replacing security roles
• Organization-wide visibility
• High volume batch updates

Access Team created
        |
Users lack base table privilege
        |
Access appears broken

Access team augements access- they never replace base privilige.

7. Sharing

What sharing does

• Creates explicit access entries
• Overrides ownership boundaries
• Adds runtime evaluation cost

When Sharing Becomes a Problem

• Thousands of shared records
• Frequent share/unshare operations
• Cross-BU collabration without design

If share is required often, redesign security

8. Field Level Security

Purpose

• Protect. sensitive columns
• Override, table-level access

Field level security doesnot secure records, it only secure columns.

Role-Based Perspective

Admin

1. Responsibilities

• BU design
• Role governance
• Team strategy
• Sharing Limits
• Performance monitoring

2. Common Failure

• Overusing sharing
• Ignoring Access teams
• Creating too many roles
• No security design documentation

Architect

1. Key Decision

• BU strategy
• Role composition
• Owner vs Access Teams
• Sharing vs Access Teams
• Performance vs flexibility trade offs

2. Failures

• Designing security bottom-up instead of top-down

Developer

1. Reality

• Security failures appear as "no data"
• API calls silently trimmed
• Plugins run under specific identity

2. Failures

• Testing as System Admin
• Ignoring Access Teams
• Assuming read=write
• Hardcoding ownership assumptions

User Experience

• Record visible but not editable
• Record disappeared but visbile for other user

Best Practices

Do

• Design security before schema
• Use Access Teams for collabration
• Limit explicit sharing
• Keep roles minimal and composable
• Document security design

Don't

• Test only as admin
• Overuse owner teams
• Ignore BU boundaries
• Grant System Administrator casually
• Treat Access Team as magic

Common Mistakes

1. Roles Control Everything
   • Role define potential access, not actual access
2. Access Teams Grant Permissions
   • They grant access only if base privilege exists
3. Sharing is fine at scale
   • Sharing is hidden performance tax

Summary

Dataverse security:

• is layered and cumulative
• Requires design, not trial-and-error
• Trades flexibility for complexity
• Scales only when patterns are intentional

Access Teams:

• Are essential for collabration
• Prevent sharing explosions
• Are often underused
• Require correct base privilege