Last updated: November 13, 2026
By ZapAI Team
Dataverse security roles decide what every person, team, app user and agent can do with records in Dynamics 365 Sales, Customer Service, Field Service and model-driven Power Apps. Our Microsoft Dataverse services team designs these models for mid-market firms, and this guide covers each layer, recent changes, a role design worksheet and our decision rules, checked against Microsoft Learn on November 13, 2026.
Dataverse security roles are sets of table privileges, each with an access level from User to Organization, that you assign to users or teams. Access is cumulative across roles, teams, sharing and hierarchy, so the broadest grant wins and no role can take access away.
Here’s a hypothetical that will sound familiar. A sales rep can’t open an account. Somebody grants System Administrator to get through the week. Two years later, a third of the company holds it. Nobody planned that.
Security in Dataverse isn’t one setting. It’s eight layers that stack, and getting the stacking wrong either blocks people from their work or quietly hands Copilot and every connected agent far more data than anyone meant to share.
This guide is for admins, IT leads and project owners at small and mid-sized firms. Our Dynamics 365 CRM customization best practices already argue for roles built around jobs, so we skip that and go a level deeper. Ignite runs November 17 to 20. Expect a refresh.
What Are the Layers of Dataverse Security?
Eight, and they stack. Environment access decides who gets in, business units and security roles decide which records and actions, teams, sharing and hierarchy widen access, and column security narrows what shows inside a record.
| Layer | What it controls | Where you set it |
|---|---|---|
| Environment access | Which licensed users can exist in the environment | Security group on the environment, Power Platform admin center |
| Business units | Security boundaries that hold users and records | Environment settings, Users and permissions |
| Security roles | Table privileges and how deep each one reaches | Security role editor in the admin center |
| Ownership and teams | Whether a user or a team owns each record | Table ownership type, team setup |
| Sharing | Exceptions, one record at a time | Share command, access team templates |
| Hierarchy security | Manager or position access to reports’ data | Hierarchy security settings |
| Column security and masking | Who reads or edits a sensitive column, and whether it shows masked | Column settings plus column security profiles |
| App access | Which model-driven apps a person can open | App sharing by security role |
One rule governs all of it. Per Microsoft’s ownership-based security overview, updated November 2, 2026, privileges are cumulative, and a user receives the broadest access granted by all their roles and team memberships put together. Roles only add. If one role grants organization-wide read on contacts, another role can’t hide a single contact.
So design from zero upward. Every grant stays granted. Until you remove it.
Who Gets Into the Environment in the First Place?
Licensed users who pass the environment’s security group, then hold at least one security role. Without a role, a user can sign in but gets an access denied error when opening an app.
Microsoft’s guide to controlling environment access, updated August 26, 2026, lists behaviors that catch admins out.
- Removing someone from the group disables them in the environment.
- Attaching a group to an environment with existing users disables everyone outside it.
- Nested group members aren’t added automatically.
- Default and developer environments can’t take a security group.
- Application users run in group-secured environments without being members.
That last bullet matters more than it looks. An integration or agent running as an application user skips your environment gate entirely, so its security role is the only thing between it and your data, which is why we review app user roles with the same care as production code. Read that twice.
Admins no longer hold System Administrator by default
Global, Power Platform and Dynamics 365 administrators no longer get the Dataverse System Administrator role automatically. To change user roles or install apps, they need self-elevation through Membership and Add me on the environment, per Microsoft’s high-privileged admin roles page. Purview logs every elevation.
Good change. With Privileged Identity Management, Microsoft removes that role when the PIM assignment expires, which finally makes temporary admin access actually temporary.
How Do Business Units Work Now?
Every Dataverse environment has one root business unit, and child units divide users and data into smaller boundaries. With the matrix model, which Microsoft calls modernized business units, a user can hold roles from several units and own records in any of them.
Classic business units are hierarchical. Each user sits in one unit and gets a role from it. Simple. Rigid, too.
Matrix access fixes that. Turn on Record ownership across business units under Settings, Product, Features in the admin center, and a user can hold roles from several units, each granting access to that unit’s records. The modernized business units page puts it plainly. The user’s own business unit no longer decides access.
Status check. Learn no longer labels the feature preview, though older partner posts still do. Expect conflicting advice.
Two details deserve a place in your plan.
- Users still need a role from their own business unit with user settings privileges to run model-driven apps.
- Data sync jobs that carry the Owning Business Unit column fail with a foreign key error when the target environment lacks that business unit, so strip or remap the column before you copy data between environments.
Our view on structure is blunt. Fewer business units. Microsoft’s hierarchy security guidance recommends fewer units plus hierarchy security over a large number of units, and we start with one root unit and add children only where a real data wall exists, like separate legal entities or a division that must never see another division’s customers.
What Do Privileges and Access Levels Control?
A security role is a grid. For each table it grants eight privileges, Create, Read, Write, Delete, Append, Append To, Assign and Share, and each privilege gets an access level that sets how far into the business unit tree it reaches.
| Access level | Reaches | Typical use |
|---|---|---|
| User | Records the user owns, plus records shared with them or their teams | Reps and agents working their own pipeline or cases |
| Business Unit | Every record in the user’s business unit | Team leads, shared service desks |
| Parent-Child Business Units | The user’s unit and every unit below it | Regional or division managers |
| Organization | Every record in the environment | Reference data, admins, executives |
| None | Nothing | Anything a persona doesn’t need |
Ownership type changes the menu. Organization-owned tables offer only Organization or None. You pick ownership when you create a table and can’t change it later, so choose user or team ownership for anything that might ever need row-level control down the road.
Microsoft’s security roles and privileges page also lists privacy-related privileges, such as Export to Excel and printing. Reviews skip those. Don’t.
Every role also carries a setting that trips people up. The default, Direct User (Basic) access level and Team privileges, lets team members use the role’s User-level privileges as if it were assigned to them personally, which is what makes assigning one role to an Entra group team work for everyone in it. Team privileges only limits those rights to records the team owns. Keep the default.
Owner Teams, Access Teams, Group Teams or Sharing?
Use Entra group teams for stable groups, owner teams when a group should own records, access teams for per-record collaborators, and sharing only for exceptions. Microsoft says sharing performs less efficiently and is harder to troubleshoot than role-based access.
Here’s how the four differ.
- Owner teams own records and hold roles. Members are added by hand.
- Entra group teams work like owner teams. Membership comes from Entra.
- Access teams own nothing and hold no roles. Records are shared to them.
- Sharing grants rights on one record. Each share becomes a row in the PrincipalObjectAccess table.
Group teams are what we reach for first. Per Microsoft’s group teams guide, a licensed new hire added to the right Entra group can open the environment immediately. Two catches. Membership is cached at sign-in, so Entra changes may wait for the next sign-in or a refresh after 8 hours of continuous sign-in, and an environment with a security group needs the team’s Entra group inside that group too.
Sharing has a real cost. The PrincipalObjectAccess storage page explains that direct shares, access team members, shares to teams and cascaded shares to child records all create rows in that table, and the default Cascade All reparent behavior on relationships like account to case multiplies them quietly. Microsoft doesn’t support deleting those rows directly. You fix growth by changing the model.
Decision rules we use
These rules blend Microsoft’s guidance with ZapAI practice. Treat the table as our default. Not a law.
| Situation | Use | Why |
|---|---|---|
| A department needs every record of a type in its area | Business Unit-level role on an Entra group team | No per-record work, and joiners and leavers follow Entra |
| A group should collectively own a queue of records | Owner team or group team as record owner | Microsoft recommends team ownership when you keep sharing with the same list of users |
| Collaborators change from record to record, like a deal team | Access team from a team template | Membership lives on the record form and ends when the work ends |
| One record needs one outside reviewer, once | Sharing | Fine as an exception, costly as a habit |
| Managers need their reports’ records | Hierarchy security | Follows the manager or position chain without new units |
| People work across divisions | Roles from several business units, matrix model on | Replaces team ownership workarounds |
| Access should follow a field value like region, on ownerless data | Filtered record ownership | Preview only, keep it in a sandbox |
When Does Hierarchy Security Make Sense?
When managers need their team’s records without a business unit per team. It’s off by default.
Per Microsoft’s hierarchy security page, updated June 22, 2026, a direct manager gets Read, Write, Append and Append To on a report’s data, and higher levels get read-only access down to the depth you set. Manager hierarchy uses the Manager field on each user. Position hierarchy uses positions you define. It crosses business units.
Two warnings. Microsoft recommends keeping the effective hierarchy to 50 users or fewer under a manager or position, using depth to stay there. And Microsoft’s own pages disagree on prerequisites, since the hierarchy page says a manager needs at least User-level Read on the table while the older page on how record access is determined says the manager’s role needs Business Unit or Parent-Child depth. Test with a real manager account.
How Do Column Security and Masking Protect Sensitive Fields?
Column security hides or locks individual columns for everyone outside a column security profile. Masking rules go further and show a partial value, like the last four digits of an account number, to people who may read the column but shouldn’t see all of it.
Setup has three parts. Enable column security on the column, optionally attach a masking rule, then grant Read, Read unmasked, Update and Create through profiles. Column security doesn’t grant record access. The user needs the row first.
Audits keep surfacing three gotchas from Microsoft’s column-level security page.
- System administrators always see secured data. Test without that role.
- A calculated or prompt column that reads a secured column can display its value. Secure both.
- Lookup, formula and primary name columns can’t be secured.
Masking needs a Managed Environment, per the masking rules page, updated October 13, 2026, which carries no preview label. Rules are regular expressions on text and number columns. Microsoft’s table says masked columns show masked values in grids, forms, Excel reports and Copilot, even for users allowed to unmask them. Reveals happen one record at a time. Each one is audited.
One limitation for help desk staff. The eye icon that reveals a value on a form currently shows only for System Administrators with Read unmasked, and Microsoft says non-admin support is coming.
Does Access to a Model-Driven App Mean Access to Data?
No. Sharing a model-driven app ties it to security roles so people can open it, but the table privileges in those roles decide what they see. Views and forms are conveniences. Not walls.
New roles created in the admin center include App Opener privileges by default, and Microsoft suggests copying App Opener for custom apps or Basic User where core tables matter. Role-based views show the limit, since Microsoft’s own page says access to a view doesn’t mean access to the data in it. Our canvas vs model-driven apps comparison explains why model-driven apps inherit this security for free.
What Changed in Dataverse Security Since Late 2025?
Seven things, in our reading of Microsoft Learn. The biggest are admin roles losing automatic Dataverse access, masking for sensitive columns, and agents getting their own identities.
| Change | Status, November 2026 | What to do |
|---|---|---|
| Tenant admins no longer auto-assigned System Administrator | In effect | Use self-elevation with PIM, clean up old assignments |
| Role editor with business unit, description, applies to and core table summary fields | In effect | Fill in descriptions so reviewers know each role’s purpose |
| Column masking rules | No preview label on Learn, Managed Environments required | Mask card, tax ID and account numbers for frontline roles |
| Record ownership across business units | No preview label on Learn | Plan the move off team ownership workarounds |
| Filtered record ownership | Public preview from October 2, 2026 | Sandbox only |
| Dataverse agent users with Microsoft Entra Agent ID | Public preview | Pilot one agent outside production |
| Copilot Studio control over maker-provided credentials | Available in the admin center | Decide per environment before agents spread |
The role editor deserves a word. New roles now carry a business unit, a description, an applies to field and a core table summary, plus presets like Reference, Private and Collaborate. The System Administrator role can’t be edited. Copy it.
Dynamics 365 Sales adds a wrinkle. Microsoft’s predefined Sales roles page lists AI agent users, such as D365 Sales LeadQual, that the Sales Qualification Agent creates whether or not you turn the agent on, and it warns that deleting them might break your deployment. Leave them alone.
How Does Security Apply to Copilot, Agents and Fabric?
Copilot answers from data the signed-in user can access. Agents act under whatever identity you give them. Data sent through Link to Fabric is governed by Fabric workspace access, not Dataverse roles.
Start with Copilot. Microsoft’s Copilot data security FAQ says its responses are based only on data you personally can access. Sounds safe. It is, if your roles are right. Broad roles give Copilot broad reach, the same lesson our Microsoft 365 Copilot oversharing guide draws for SharePoint, and masked columns stay masked in Copilot, which makes masking a cheap guardrail before any rollout.
Agents need more thought. A Copilot Studio tool can authenticate with the maker’s credentials, and then every user of the agent acts with the maker’s access. Microsoft’s maker credentials control page warns this can overshare data, notes both options are on by default, and lets admins force end-user credentials. The catch? Scheduled and event-triggered agents then fail, since every tool call needs a live sign-in.
For agents that must run alone, Microsoft is moving toward dedicated identities. The Entra agent users page describes a Dataverse agent user tied to an agent’s Microsoft Entra Agent ID, with its own security roles. It’s a public preview. Pilot it. Our Dataverse MCP server guide covers the user-context route instead.
Fabric is the gap people miss. Link to Fabric creates a replica that Microsoft calls governed and secured by Dataverse, but you then grant people access to the Fabric workspace, and from there workspace roles and OneLake security decide who reads what. Nothing on Learn says business unit walls or column profiles follow the rows, as our Dataverse Link to Fabric guide explains. Rebuild those restrictions first.
How Should You Design Dataverse Security Roles?
We design roles in seven steps, built from Microsoft’s guidance and our own projects. Map personas, keep units few, copy base roles, set depth, name everything, assign through groups, and test as a real user.
- List personas, not people.
- Draw the smallest business unit tree that matches real data walls.
- Copy a base role per persona. App Opener, Basic User, or the closest Dynamics 365 role, like Salesperson.
- Set each table’s privileges and depth, starting from None.
- Name roles with a fixed pattern and fill in the descriptions.
- Assign roles to Entra group teams. Keep System Administrator to two or three named people.
- Test every persona with a non-admin account, then ship roles through your pipeline.
Step three has a trap, documented on that same Sales roles page. Custom copies don’t inherit new permissions Microsoft later adds to the original role, so after a major update a copied Sales Manager role can quietly miss a new feature your sellers expect. Microsoft’s check is simple. Assign the predefined role to a test user, and if the task works, add the missing privileges to your copy.
Naming sounds trivial. It isn’t. We use company prefix, app, persona and scope, separated by hyphens, so a hypothetical firm called Acme might have ACME-SLS-Rep-BU and ACME-SVC-Agent-User, and sorted alphabetically every role for one app sits together while the suffix tells an auditor the depth before they open anything.
A role design worksheet
Below is the worksheet we fill in before touching the admin center. The rows are an example for a hypothetical distributor running Dynamics 365 Sales and a custom warranty app.
| Role name | Copied from | Key tables and depth | Assigned to | Column profile | Test account |
|---|---|---|---|---|---|
| ACME-SLS-Rep-BU | Salesperson | Account and contact Read at Business Unit, Write at User. Opportunity Create, Read and Write at User. Delete None. | Entra group team, Sales unit | None | test.salesrep |
| ACME-SLS-Manager-PCBU | Sales Manager | Opportunity Read at Parent-Child, Write at Business Unit. Hierarchy security on. | Entra group team, Sales unit | Margin columns Read | test.salesmgr |
| ACME-WAR-Clerk-User | App Opener | Warranty claim Create, Read and Write at User. Product Read at Organization. | Entra group team, Service unit | Serial and card columns masked | test.warranty |
| ACME-FIN-Viewer-Org | Basic User | Account, order and invoice Read at Organization. No Create, Write or Delete. | Entra group team, root unit | Credit limit Read | test.finance |
| ACME-INT-ERP-App | App Opener | Only the tables the integration writes, at Organization. | Application user | Read unmasked only if the ERP needs raw values | Sandbox run |
Then test. Sign in as each test account, do the job, and try a few things the persona must not do, like deleting an account or opening a margin column they shouldn’t see. Check Access on a record shows whether access came from a direct role, a team role, sharing or hierarchy. Fix the role, not the user.
Deployment packages have a limit here. Roles and column security profiles travel between environments inside them through your Power Platform ALM pipeline, but business units, teams and user assignments don’t, so each environment needs its own setup checklist.
What Mistakes Do We See Most?
Most problems we fix trace back to convenience. Someone needed access fast, got a broad role, and nobody took it back.
- System Administrator handed out to fix one error.
- A business unit per department.
- Sharing as the default model.
- Testing security as an admin.
- Hidden form tabs treated as protection.
- Copied roles missing new privileges.
- Application users holding System Administrator because a vendor asked.
- Agents wired to maker credentials in production.
Regulated firms carry extra weight. Our Dynamics 365 HIPAA guide covers what the Microsoft BAA leaves to your configuration, and the security model above is where that work lands.
Dataverse Security Checklist
Run this list before go-live and again every quarter. For a small org, we budget an afternoon.
- Security group on every production environment.
- System Administrator limited to named people.
- PIM for tenant admins.
- Business units kept to real data walls.
- Every custom role copied, named and described.
- Roles assigned through Entra group teams.
- Delete, Assign and Export to Excel reviewed.
- Repeat shares replaced by team ownership.
- Hierarchy depth set.
- Column security on sensitive fields.
- App users and agents on least-privilege roles.
- Maker credentials decision made.
- Fabric workspace access rebuilt.
- Persona tests rerun after major updates.
Environment-level controls like data policies and Managed Environments sit one level up, in our Power Platform governance guide.
What Could Change After Ignite 2026?
Agent identity is the likely headline. Ignite runs November 17 to 20, 2026, in San Francisco, and agent users, filtered record ownership and credential controls could all change status. We’ll refresh this post by late November.
Wrapping Up
Design Dataverse security top down and grant access bottom up. Gate the environment, keep business units few, copy base roles and set depth table by table, prefer group teams over sharing, add hierarchy and column security where the job demands it, and test every persona without admin rights. Then watch agents and Fabric. Roles stop at their edges.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Dataverse consultants design security models for Dynamics 365 Sales, Dynamics 365 Customer Service and custom model-driven apps, and clean up inherited ones. Want a second opinion? Ask us for a Dataverse security review, and we’ll map your roles, teams and sharing before anything changes.
Questions Admins Ask About Dataverse Security
What’s the difference between a security role and a business unit?
A business unit is a boundary that holds users and records. A security role is a set of privileges with access levels, and the Business Unit or Parent-Child levels in a role only make sense relative to that boundary. You need both.
Can one security role remove access another role grants?
No. Privileges are cumulative across roles and team memberships, and the broadest grant wins. To take access away, remove or narrow the role that grants it.
Do system administrators see secured or masked columns?
Secured columns, yes. Microsoft says column-level security doesn’t apply to the System Administrator role, so test with a non-admin account. Masked columns still show masked values by default, and each reveal is audited.
Should we use owner teams or access teams?
Owner or Entra group teams when the same group works the same records over time. Access teams when collaborators change from record to record. Both beat sharing records one user at a time, which Microsoft says performs less efficiently.
Can Copilot show a user records they can’t open?
Not according to Microsoft. Its Copilot data security FAQ says responses are based only on data the user can personally access. Agents differ, since a tool using maker credentials acts with the maker’s access.
Are modernized business units still in preview?
Microsoft Learn no longer labels record ownership across business units as preview, as of its November 2, 2026 update. Filtered record ownership, a newer option based on column values, is still a preview.
Do security roles move between environments with our app?
Roles and column security profiles do, inside your deployment packages. Business units, teams and user role assignments don’t, so set those up per environment.