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.

A worked example — designing security for a mid-market Sales rollout

The right way to design security is bottom-up from what users must not see. Take a two-region sales organisation with a shared inside-sales team and a global marketing group:

1. Business units. Root BU = the company. Two child BUs — "EMEA" and "Americas" — for regional sales. That is the whole tree; the inside-sales and marketing teams sit at the root and get scoped through team membership.
2. Roles. Start from the built-in Salesperson role. Copy → "Salesperson EMEA" and "Salesperson Americas". Both remain at user and business unit scope for Account, Contact, Opportunity, Lead. Do not escalate to organisation on any owned entity — that is the mistake that lets an EMEA rep see every American deal.
3. Inside-sales team. An owner team called "Inside Sales" at the root BU, granted a copy of the Salesperson role with organisation-scoped Read on Account, Contact, Lead — because they qualify inbound leads globally. Write is left at user scope; qualified leads are handed off to the regional owner.
4. Marketing. A separate role granting Read on Contact and Account at organisation scope, plus full write on Marketing Lists. No access to Opportunity — marketing does not need to see deal values.
5. Manager visibility. Enable the manager hierarchy for Opportunity and give sales managers organisation-scope Read via hierarchy only. They see their reports' pipelines without becoming full org-wide readers.
6. Field-level security. One profile called "Compensation" on the User table's salary and commission-plan columns. Members: HR team. Everyone else's read is denied on those fields.

The whole model above is defensible in an audit, admin overhead is low, and it scales — adding a third region is a new child BU plus a new role copy, not a schema change.

Common mistakes and how to avoid them

• Role-per-user. Cloning a role for every individual because "their access is a bit different" produces dozens of near-identical roles nobody can maintain. If two users need different access on the same table, that is a team difference, not a role difference — put them on different teams with different role grants.
• Organisation-scope everywhere. Every scope escalation removes a boundary permanently — you cannot claw back visibility once users are used to it. Start at business unit and escalate on evidence of pain, not on suspicion of need.
• Sharing as the design. Row sharing is a safety valve, not a security model. If dozens of records are shared programmatically every day, the underlying model is wrong — reshape the BUs, teams, or scopes instead.
• Ignoring privilege inheritance on activities. Access to a related activity (email, phone call) is inherited from the regarding record. A user without Read on Opportunity cannot see the activities logged against it, even if their Activity role is generous. This is intentional — do not "fix" it by granting Activity organisation Read.
• Field-level security on formula columns and lookups. Both have historical restrictions and edge cases (lookup name display, formula recalculation using restricted columns). Test carefully before turning on FLS for either.
• Editing built-in roles directly. They are re-published on release-wave updates; your changes will be overwritten. Always copy first, edit the copy.

Decision matrix — which mechanism to use

Need	Right mechanism
A regional team should see its own region's data only	BU + role at BU scope
A user needs one-off access to a specific record	Row sharing
A group of users needs a role but membership changes often	Owner team + role on the team
A group needs record-level rights only for specific record types (e.g. big deals)	Access team + row-level grant via a plugin or flow
Managers should see their reports' data	Manager hierarchy + hierarchy scope on the role
A column contains sensitive data (SSN, salary)	Field-level security profile
A completely separate tenant of data (e.g. franchisee model)	Separate environment, not just BUs

Wrong-fit signals — when to reach for a new environment instead

BUs and roles are for logical partitioning inside one dataset. When you find yourself needing physical separation — a franchisee that must not see other franchisees' data even in the event of a support-role misconfiguration, or a regulated subsidiary with its own encryption keys — the answer is a separate Dataverse environment, not a bigger BU tree. The extra licence cost is smaller than the security-incident risk from over-loading the security model.

Rollout checklist

• Map the "must not see" list before drawing any BUs.
• Draft the BU tree, then challenge every branch — flatter is better.
• Copy built-in roles, do not edit them.
• Default every privilege to business unit scope; document any escalation.
• Design team membership at the same time as roles; roles alone rarely land the right access.
• Turn on audit for tables holding sensitive data before user testing.
• Field-level security only where a column contains data other cleared users on the same record must not see.
• Run a matrix walkthrough — pick 6 representative users, list what each should and should not be able to do, and prove the model matches.
• Book a quarterly access review; put it on the ops calendar, not the project plan.

Where to go next

Each layer has its own guide: business units and teams, owner teams vs access teams, field-level security, and hierarchical security. The privilege errors a wrong role produces — 0x80040220 and friends — are decoded in Dataverse Web API errors.