3.2 Security Roles, Privileges & Depth Levels

3.2 Security Roles, Privileges & Depth Levels

Security Roles in Microsoft Dataverse constitute the core mechanism for defining what actions a user or team can perform on specific records, tables, and system components. Rather than managing individual user permissions on an ad-hoc basis, Dataverse groups capabilities into Security Roles composed of granular Privileges configured at distinct Depth Levels.

Mastering privilege depth mechanics, the interaction between relational privileges like Append and Append To, and the cumulative evaluation algorithm is essential for designing robust, least-privilege enterprise architectures.

---

1. The 8 Core Record-Level Privileges

For every User/Team-owned table in Dataverse, security roles provide eight distinct record-level privileges that govern the complete lifecycle of data entities.

+-----------------------------------------------------------------------------------+
|                     THE 8 DATAVERSE RECORD-LEVEL PRIVILEGES                       |
|                                                                                   |
|    [CREATE]  --------> Instantiates a new record row in the table                 |
|    [READ]    --------> Views record data in forms, views, reports, and API queries|
|    [WRITE]   --------> Modifies existing column values on an active record        |
|    [DELETE]  --------> Permanently deletes or deactivates the record             |
|    [APPEND]  --------> Attaches ANOTHER entity record to THIS record             |
|    [APPEND TO] ------> Attaches THIS record to ANOTHER entity record             |
|    [ASSIGN]  --------> Changes the owner (systemuser/team) of the record          |
|    [SHARE]   --------> Grants ad-hoc read/write/share rights via POA table       |
+-----------------------------------------------------------------------------------+

Detailed Privilege Breakdown

1. Create: Grants permission to instantiate a new record row. The user's depth level for Create dictates in which Business Unit the record can be created.
2. Read: Grants permission to view record data in model-driven forms, canvas galleries, Power Pages lists, system views, Power BI reports, and Dataverse Web API endpoints.
3. Write: Grants permission to edit and update existing column values on an existing record row. (Note: Modifying sensitive individual columns can be further restricted by Column-Level Security).
4. Delete: Grants permission to permanently remove a record from the database.
5. Append (The "Container" Right): Grants the right to attach other records to this record. Think of this as opening the record's pocket to hold child records.
6. Append To (The "Passenger" Right): Grants the right for this record to be attached to another record. Think of this as permission for this record to climb into another record's pocket.
7. Assign: Grants permission to transfer ownership of a record to another user or team. Assigning a record updates the ownerid and owningbusinessunit fields.
8. Share: Grants permission to delegate specific access rights (such as Read or Write) on an individual record to another user or team without transferring ownership.

The "Append" vs. "Append To" Rule

To link two records together via a 1:N or N:N relationship (such as linking a Contact to a parent Account):

• The user MUST have the Append To privilege on the Parent entity (Account) because the Account is being appended to.
• The user MUST have the Append privilege on the Child entity (Contact) because the Contact is being appended into the Account relationship.

+-----------------------------------------------------------------------------------+
|                         APPEND VS. APPEND TO MECHANICS                            |
|                                                                                   |
|   SCENARIO: Link Contact 'Alice' to Parent Account 'Contoso Corp'                 |
|                                                                                   |
|   +--------------------------+                   +--------------------------+     |
|   |     ACCOUNT (Parent)     |                   |     CONTACT (Child)      |     |
|   |       'Contoso'          | <================ |         'Alice'          |     |
|   +--------------------------+                   +--------------------------+     |
|   Requires: [APPEND TO] on Account               Requires: [APPEND] on Contact    |
|   (Permission to be target of link)              (Permission to link into target) |
+-----------------------------------------------------------------------------------+

---

2. Privilege Depth Levels (Visual Circles & Hierarchy Scopes)

Privilege depth determines the organizational scope across the Business Unit hierarchy tree in which a user can exercise a specific privilege. In the modern Power Platform Admin Center and classic role editor, these are represented by concentric circular symbols.

+-----------------------------------------------------------------------------------+
|                    DATAVERSE PRIVILEGE DEPTH LEVELS MATRIX                        |
|                                                                                   |
|   Symbol      Depth Tier           Organizational Scope                           |
|   -----------------------------------------------------------------------------   |
|   [ ] Empty   None                 No privilege granted for this action.          |
|   (•) 1/4     Basic (User)         Records owned by the user or shared with user. |
|   (◐) 1/2     Local (BU)           Records owned by ANY user/team in the user's BU|
|   (◕) 3/4     Deep (Parent-Child)  Records in user's BU + ALL descendant child BUs|
|   (●) Full    Global (Organization)Records across the ENTIRE environment.         |
+-----------------------------------------------------------------------------------+

Detailed Depth Tier Analysis

[!NOTE] For Organization-owned tables, only None and Global (Organization) depth levels are supported because organization-owned records do not carry an owningbusinessunit or ownerid attribute.

---

3. Miscellaneous & Administrative Privileges

Beyond table-level CRUD permissions, Dataverse security roles control global features, admin capabilities, and platform tooling via miscellaneous privileges distributed across various functional tabs:

• Core Records Tab: Controls global features like Export to Excel, Mail Merge, Bulk Edit, and Print Records.
• Business Management Tab: Governs organizational settings, currency management, fiscal year settings, and user administration.
• Customization Tab: Controls solution authoring, entity customization, and the critical Publish Customizations (prvPublishCustomizations) privilege.
• Service Management / Sales Tabs: Controls queues, knowledge base articles, products, and routing rules.
• Critical Administrative Privileges:
  • Act on Behalf of Another User (Impersonation): Required for background integration flows, sync tools, and web services that execute API calls impersonating a target user identity (prvActOnBehalfOfAnotherUser).
  • Execute Workflow Job / Cloud Flows: Allows users to trigger background automations and on-demand cloud flows.
  • View Audit History / Partition Logs: Allows security officers and compliance leads to inspect historical change tracking data.

---

4. Cumulative Privilege Evaluation & ALM Governance

When a user logs into a Power Platform app or executes an API call, Dataverse dynamically calculates the user's effective permissions using a cumulative union model.

+-----------------------------------------------------------------------------------+
|                    CUMULATIVE PRIVILEGE EVALUATION LOGIC                          |
|                                                                                   |
|   Direct User Security Role:                                                      |
|     - Account Table: Read = Basic (User Depth)                                    |
|     - Contact Table: Write = None                                                 |
|                                     +                                             |
|   Team A (Owner Team) Security Role:                                              |
|     - Account Table: Read = Local (Business Unit Depth)                           |
|     - Contact Table: Write = Basic (User Depth)                                   |
|                                     +                                             |
|   Team B (Entra ID Group Team) Security Role:                                     |
|     - Account Table: Read = Global (Organization Depth)                           |
|     - Contact Table: Write = None                                                 |
|                                     ||                                            |
|                                     v                                             |
|   EFFECTIVE CUMULATIVE PERMISSIONS:                                               |
|     - Account Table: Read = GLOBAL (Organization Depth)  [Most Permissive Wins!]  |
|     - Contact Table: Write = BASIC (User Depth)         [Least Restrictive Union] |
+-----------------------------------------------------------------------------------+

Cumulative Privilege Rules

1. Most Permissive Wins: If Role 1 grants Local (BU) Read on Accounts and Role 2 grants Global (Organization) Read on Accounts, the user's effective Read privilege is Global.
2. No Subtractive Roles: In Dataverse, security roles are purely additive. You cannot create a "deny" role that subtracts or revokes a privilege granted by another assigned role.
3. User-Depth Team Privileges: If a user receives a security role with Basic (User) privilege depth through an Entra ID Group Team, the user can act on records owned by the team or records they own personally (if configured for Direct User access).

Application Lifecycle Management (ALM) Best Practices

• Never Edit Default Out-of-the-Box Roles: Never modify out-of-the-box system roles like Basic User, Salesperson, or System Customizer directly in the Root BU. Future Microsoft platform updates can overwrite standard role definitions.
• Copy and Customize in Solutions: Always use the Copy Role action to duplicate a base role into a custom named role (e.g., contoso_FieldSalesRepresentative) inside a dedicated Unmanaged Solution.
• Include Security Roles in ALM Pipelines: Export custom security roles within your Managed Solution package when deploying across Test, UAT, and Production environments.