The Dataverse security model

Dataverse security looks intimidating from the outside but reduces to a handful of layered concepts. Once they click into place, designing security for a Dynamics 365 implementation becomes a methodical exercise rather than guesswork.

Business units (BUs). The root of the security model. Every Dataverse environment has a tree of business units with a single root and any number of children. Every user and every record belongs to a BU. BUs typically map to organisational structure — divisions, regions, subsidiaries — and form the scope boundary for security roles.

Security roles. A security role grants privileges (create, read, write, delete, append, append-to, assign, share) on each Dataverse table. Each privilege has a scope: user-owned, business unit, parent: child business unit, or organisation — meaning the user can act on their own records, on records owned by their BU, on records owned by their BU or its children, or on all records. The intersection of role + scope is what determines a user's effective access. Multiple roles combine additively.

Teams. A team is a collection of users. Teams can own records, and security roles can be assigned to teams to grant access to all team members. Owner teams behave like users; access teams are lightweight groups for ad-hoc record sharing. Microsoft 365 groups can be linked as teams.

Row sharing. Records can be shared with a user or team for specific privileges, granting access outside the regular scope rules. Sharing is the safety valve when default scopes don't fit — but heavy reliance on sharing complicates audit and admin.

Field-level security. Beyond row-level, field-level security profiles restrict access to specific columns (e.g. salary on the User table). Profiles list users or teams that can read, update, or both, on each protected field. Use sparingly — every protected field adds maintenance.

Hierarchies. Manager and position hierarchies offer an additional scope dimension where users with manager rights can see records owned by their direct or indirect reports.

Auditing. Audit is enabled per table and column. Every change to an audited column is recorded with user, timestamp, old value, new value. Long-term retention pushes audit data to Microsoft Purview for compliance.

Practical advice.

• Start from Microsoft's built-in roles (e.g. Salesperson, Customer Service Rep); copy and edit.
• Use BUs sparingly — too many makes admin painful.
• Default to BU-level scope; jump to organisation only with a real reason.
• Audit access reviews quarterly.