Skill: Dataverse Security Model

When to Use

Security Model Overview

Entra ID (Authentication)
  └── Confirms identity ("who are you?")

Dataverse Security (Authorization)
  ├── Security Roles          → Table-level CRUD + access depth
  ├── Column Security         → Field-level read/update control
  ├── Row-Level Security      → Record ownership + sharing
  ├── Business Units          → Organizational hierarchy
  ├── Teams                   → Group-based access
  └── Hierarchy Security      → Manager/position chain visibility

⚠️ REQUIRED: Load Sub-Files Before Implementation

read_file

• Roles & Privileges — Access levels (User/BU/Parent:Child/Org), privileges (CRUD + Append/AppendTo/Assign/Share), standard role patterns, minimum viable privileges
• Row & Column Security — Column security profiles, field permissions, row-level patterns (ownership, sharing, hierarchy)
• Business Units & Teams — BU hierarchy design, owner teams, access teams, Azure AD Group Teams, record sharing (GrantAccess/RevokeAccess)
• Web API Management — Security role CRUD via Web API, privilege queries, role assignment to users/teams, field security profile management

Security Design Checklist

## Security Model Design: [Solution Name]

### Tables & Access Matrix
| Table | App Admin | App Manager | App User | App Reader |
|---|---|---|---|---|
| contoso_project | Org CRUD | BU CRUD | User CRW | Org R |
| contoso_task | Org CRUD | BU CRUD | User CRUD | Org R |
| contoso_resource | Org CRUD | BU R | User R | Org R |

### Column Security
| Table | Column | Who Can Read | Who Can Update |
|---|---|---|---|
| contoso_project | contoso_budget | Finance Team, App Admin | Finance Team |
| contact | contoso_salary | HR Team | HR Team |

### Validation
- [ ] Test as each role — verify CRUD boundaries
- [ ] Test cross-BU access — verify isolation
- [ ] Test column security — verify restricted fields masked
- [ ] Test with no roles — verify access denied
- [ ] Verify lookup target tables have Read access
- [ ] Verify AppendTo on lookup target tables

Power Pages Table Permissions Audit

1. Missing Permissions (Critical) — Table used in code but no permission exists (403)
2. Overly Broad Scope (Warning) — Global scope with write/delete enabled
3. Missing Append/AppendTo (Critical) — Tables with lookups need append on source, appendto on target
4. Orphaned Permissions (Info) — Permission exists but table not used in code
5. Missing Web Role Association (Warning) — Permission without web role has no effect
6. Parent Chain Integrity (Critical) — Parent scope with broken parent reference grants no access
7. CRUD Excess (Warning) — More privileges than code uses (principle of least privilege)

Anti-Patterns

• Giving users System Administrator role ("just make it work")
• Single security role for all users (no least-privilege)
• Not testing access as each role type
• Missing AppendTo on lookup target tables (causes confusing save errors)
• Not scoping environment variables/connection references with appropriate read access
• Creating security roles in root BU when they should be BU-scoped
• Over-sharing records (share individually instead of using teams)
• Not using Azure AD Group Teams when Entra ID groups already exist
• Column security without a clear policy (inconsistent protection)
• Cascade delete configured without considering security implications
• Org-owned tables when row-level isolation is needed
• Using hierarchy security without clear organizational structure

Related Skills

• dataverse

  — Table and relationship design that security roles protect

• dataverse-web-api

  — Security role and privilege management via API

• power-pages

  — Table permissions and web roles for portal security

• testing

  — Security role testing strategy

• plugins

  — Plugin execution context and impersonation