Managing Temporary User Access in Dataverse with Access Teams

Access Teams let you give people access to one specific record, not the whole table.

Access Teams in Microsoft Dataverse are a powerful way to provide temporary, record-level access to users without changing the ownership of the record or assigning full security roles. They are especially useful in scenarios where multiple users need to collaborate on a single record, such as cases, opportunities, or projects, for a limited period. Access Teams rely on Access Team Templates, which define specific permissions like read, write, append, append-to, assign, and share, applied only to the selected record. Internally, when a user is added to an Access Team, Dataverse creates entries in the PrincipalObjectAccess (POA) table, which tracks who can access which record and what level of access they have. This approach ensures precise, controlled access, reduces security risks, and allows dynamic collaboration without the complexity of assigning security roles or changing record ownership. Access Teams also support automation, enabling users to be added or removed based on record lifecycle events, making them ideal for approval workflows, case escalations, or temporary project collaboration. However, Access Teams should be used judiciously, as excessive use can cause POA table growth, impacting system performance, and they are not suitable for permanent access or ownership scenarios.

What Permissions Does an Access Team Provide?

Access Teams do not own records.

They only grant access rights defined in an Access Team Template.

Supported permissions:

Read
Write
Append
Append To

Cannot grant:

Delete
Assign
Share
Create

Permissions apply only to the specific record, not all records.

How Access Teams Work (Behind the Scenes)

You create an Access Team Template
Template defines:

Entity (table)
Permissions

Access Team is automatically created per record
Users added to the Access Team get row-level access
Internally, Dataverse creates POA (PrincipalObjectAccess) entries

What is Share permission in a Security Role?

Share is an entity-level privilege in a security role.

It allows a user to:

Share a record they already have access to
Grant access to other users or teams
Control permissions like Read / Write / Append on that record

Share permission does NOT give access by itself.

It only allows the user to grant access to others.

What is an Access Team?

Access Teams are a structured way of sharing records using:

Access Team Templates
Predefined permission sets
Automatic POA (PrincipalObjectAccess) entries

They provide temporary, record-level access without:

Changing ownership
Assigning roles

Key Difference:

Architect Decision Rule

If users decide → use Share permission
If the system decides → use Access Teams

Share permission enables users to manually share records, while Access Teams provide a governed, template-based approach for temporary, record-level collaboration. Access Teams are preferred for structured, repeatable business scenarios.

Dataverse security is designed as a layered architecture to ensure data is protected while still allowing flexible collaboration, and Access Teams play a key role within this model. At the foundation, Business Units define organizational boundaries and control the maximum scope of data access. On top of this, Security Roles determine what actions a user can perform—such as create, read, write, or delete—but not which specific records they can access. Ownership (user or owner team) then decides who naturally owns and manages a record. When business scenarios require exceptions to this standard access—such as temporary collaboration, approvals, or escalations—the sharing layer comes into play. This is where Access Teams are used. Access Teams are created using Access Team Templates, which define the exact record-level permissions (for example, read or write) to be granted. When users are added to an Access Team for a specific record, Dataverse stores this access internally in the PrincipalObjectAccess (POA) table, ensuring controlled and auditable record-level security. Unlike Owner Teams, Access Teams do not have security roles and do not own records; they simply extend access in a governed, temporary, and scalable way. This architecture allows Dataverse to balance strong security controls with real-world collaboration needs, making Access Teams a clean and efficient solution for managing record-level access without compromising the overall security design.

What happens in Dataverse when a user is added or removed from an Access Team?

When a user is added:

Access Team Template is evaluated
Dataverse creates POA entries
Permissions are applied instantly
Record ownership remains unchanged

When a user is removed:

Related POA entries are deleted
User immediately loses access
No role or ownership change occurs

Fast
Secure
Reversible

What are the limitations of Access Teams?

Key limitations:

Cannot own records
No security roles
No create or delete permissions
Not suitable for long-term access
POA table can grow if not cleaned up
Not ideal for high-volume sharing

Architect Tip

Overusing Owner Teams can complicate ownership
Overusing Access Teams can grow the POA table
Choose based on business intent, not convenience

What are common mistakes teams make while using Access Teams?

Common Mistakes

Summary:

Access Teams in Dataverse are a specialized security mechanism designed to provide temporary, controlled, and record-level access without changing record ownership or expanding a user’s security role. They work through Access Team Templates, which define the specific entity and permissions—such as Read, Write, Append, Append To, Assign, or Share—that team members will receive for an individual record. When a user is added to an Access Team, Dataverse enforces access by creating entries in the PrincipalObjectAccess (POA) table, ensuring that permissions apply only to that specific record and nowhere else. Unlike Owner Teams, Access Teams do not have security roles and cannot own records; instead, they act as a lightweight sharing layer within the Dataverse security architecture. This makes them ideal for scenarios such as approvals, case escalations, compliance reviews, and cross-functional collaboration where access must be time-bound, auditable, and consistent. By centralizing permissions in templates and enabling automation for adding and removing users, Access Teams help organizations implement least-privilege access, reduce manual sharing risks, and maintain strong governance and performance in enterprise-scale solutions.

Published on: February 03, 2026

Learn more

Power Platform , D365 CE & Cloud

Dynamics 365 CE, Power Apps, Powerapps, Azure, Dataverse, D365,Power Platforms (Power Apps, Power Automate, Virtual Agent and AI Builder), Book Review

Blog image

Power Platform , D365 CE & Cloud

Dynamics 365 CE, Power Apps, Powerapps, Azure, Dataverse, D365,Power Platforms (Power Apps, Power Automate, Virtual Agent and AI Builder), Book Review

Learn more

Managing Temporary User Access in Dataverse with Access Teams

Related posts

SharePoint: MONTH function

Migrating EWS notifications to Microsoft Graph

Microsoft 365 & Power Platform Community Call – June 11th, 2026 – Screenshot Summary

Office 365 Outlook Get Attachment

Fix invalid Microsoft service API permissions in SharePoint

AI At Your Own Pace | Episode 2 | Teams Get to Choose

Microsoft Dynamics 365 vs Salesforce: A Practical Comparison for Enterprise Teams

Restricting Access is The Most Important Step in a Microsoft 365 Copilot Deployment

Microsoft 365 Copilot in Word: Improved support for complex edits

Copilot Notebooks available in Microsoft 365 Copilot Chat for Basic users