[object Object]

A security audit lands and the auditor asks one question: who can see this account, and why? In a clean Dataverse environment, the answer is a 30-second exercise. In a typical environment, it takes half a day to trace the security role, the business unit, the team membership, and the share grants. The model is powerful and the failure modes are familiar.

Security Roles

Privileges (create, read, write, delete, append, append-to, assign, share) applied to tables, with access levels (user, BU, parent-child, org). Every user needs a role. The privilege times access level is the matrix; misconfiguration in either dimension is what leaks data.

Privilege x Access Level matrix per table:
            User    BU      Parent-Child  Org
Create      .       .       .             .
Read        .       .       .             .
Write       .       .       .             .
Delete      .       .       .             .
Append      .       .       .             .
Append-To   .       .       .             .
Assign      .       .       .             .
Share       .       .       .             .

Document each role in this matrix and review quarterly. Role drift is the most common security finding.

Business Units

BUs create data boundaries. User-level access limits to records you own; BU-level to records in your BU. Model BUs on your org structure. The BU tree should match how your business escalates and reports, not how it organizes for marketing or finance.

Common BU structures:
- Geographic: World > Region > Country > Office
- Functional: Org > Sales/Service/Marketing
- Hybrid: Org > Region > Function (most common)

Restructuring BUs after launch is expensive. The hierarchy drives security; changing it forces re-validation of every role.

Teams

Users can belong to teams. Teams can own records. Shares records with the team’s members. Useful for cross-BU collaboration. Teams come in three flavors: owner teams (can own records), access teams (share via team membership), and AAD-group teams (sync from Entra ID).

Team type decision:
- Owner team: when a record is collectively owned
- Access team: when ownership stays with one user but a group needs access
- AAD group team: when team membership is managed in Entra

AAD group teams are the modern default. They reduce the manual team membership maintenance that plagues older environments.

Hierarchical Security

Manager hierarchy grants managers access to direct reports’ data. Useful; configure carefully to avoid unintended data exposure. The depth setting controls how many levels up the chain inherit access; default is one (direct manager only).

Hierarchy config:
- Type: Manager (most common) or Position (org-chart based)
- Depth: 1 (direct), 2 (skip-level), or higher
- Privileges: Read or Read-Write per table

Depth above 2 is rarely useful and frequently causes audit findings. Keep it shallow.

Common Misconfigurations

Giving Organization access level when Business Unit would do. Not restricting Append-To privileges (they control whether a record can be associated, not just opened). Audit quarterly. The Append-To misconfiguration is subtle; a user with Read on Account but no Append-To cannot link an Activity to that Account, which manifests as a confusing UI error.

<fetch>
  <entity name="role">
    <attribute name="name" />
    <link-entity name="roleprivileges" from="roleid" to="roleid">
      <link-entity name="privilege" from="privilegeid" to="privilegeid">
        <attribute name="name" />
        <filter>
          <condition attribute="accessright" operator="eq" value="134217728" />
        </filter>
      </link-entity>
    </link-entity>
  </entity>
</fetch>

This finds roles with Org-level access on any privilege. Review the list against business need.

Field-Level Security

For columns that contain sensitive data (SSN, salary, contract terms), use Field-Level Security profiles to override the role-based read or write. FLS adds another dimension to the audit but is necessary for compliance with data classification.

Auditing the Effective Permission

The Test User Permission tool in the maker portal shows what a specific user can do on a specific record. Use it during role design and during audit findings. The output is more reliable than reading the role matrix because it accounts for inheritance, hierarchy, and shares.

What to do this week

Run the privilege audit query, document each role in the matrix, and audit Append-To grants on your top five tables. Switch any owner teams to AAD group teams where the membership is already managed in Entra.

[object Object]
Share