Table of contents

1. What are Access Teams?
2. Access Teams vs Owner Teams — when to use which
3. How Access Teams work (sharing model & templates)
4. Step-by-step: Configure Access Teams (UI)
5. Step-by-step: Create Access Team Template in Power Platform admin
6. Adding Access Team controls to entity forms & subgrids
7. Programmatic scenarios (Dataverse / SDK / Web API)
8. Limits and important configuration settings
9. Security considerations & best practices
10. Troubleshooting & common pitfalls
11. Further learning & reference links

1. What are Access Teams?

An Access Team in Dynamics 365 / Dataverse is a light-weight collaboration construct used to share individual records with a group of users without changing record ownership or assigning security roles to the team itself. Access teams do not own records and you cannot assign security roles to them — instead the record is shared with the team and each team member’s access to the record is determined by the team’s granted access rights plus that user’s own security roles.

Key point: Access teams are about record-level sharing (collaboration), not ownership or team-level roles.

(Microsoft docs: access teams do not own records and do not have security roles; records are shared with an access team.) :contentReference[oaicite:0]{index=0}

2. Access Teams vs Owner Teams — when to use which

Use Owner Teams when you want a team to own records, or when you want to assign a security role to a team (a team becomes a security principal). Use Access Teams when records remain owned by an individual/user or owner team but you need to grant record-level access to a changing set of collaborators without creating ownership churn.

• Owner Team: Can own records; can be given security roles; good for shared ownership scenarios.
• Access Team: Cannot own records; no security roles assigned to the team; ideal for ephemeral or dynamic collaboration on records.

(Reference: explanation and comparison in MS docs.) :contentReference[oaicite:1]{index=1}

3. How Access Teams work (sharing model & templates)

There are two flavors often discussed:

1. Manual Access Teams — created as regular Team records of type Access; you then share records with that team.
2. Auto-created (system-managed) Access Teams via Templates — Dataverse can create a small access team automatically for each record (row) using an Access Team Template (TeamTemplate). The template defines which entity and which access rights (Read, Write, Append, AppendTo, Share, Assign) the auto-created team will have for that record. A UI control on the form (Associated Record Team Members) lets users add people to that record’s access team quickly.

(Auto-created teams require enabling AutoCreateAccessTeams on the entity and a TeamTemplate; see Microsoft guidance.) :contentReference[oaicite:2]{index=2}

4. Step-by-step: Configure Access Teams (UI)

Quick UI steps (classic / modern steps vary slightly):

1. Go to Power Platform admin center or Dynamics 365 Settings → Advanced settings → Customizations → Customize the entity.
2. Open the entity definition and find the Communication & Collaboration section and check Access Teams (or “Auto create Access teams” depending on version).
3. Save and Publish the entity changes.
4. In the entity form editor, add the Associated Record Team Members subgrid/control to the main form where you want users to manage the access team members for a record.

(MS docs: enable Access Teams on the entity and add the Associated Record Team Members control to forms.) :contentReference[oaicite:3]{index=3}

5. Step-by-step: Create an Access Team Template (Power Platform admin)

Auto-created Access Teams require a template. Steps:

1. Sign in to the Power Platform admin center as an admin.
2. Select the environment → Settings → Templates → Access team templates.
3. Click + New, give the template a name, choose the Entity (table) that’s enabled for access teams, and select the Access rights the access team will have (e.g., Read, Write, Share).
4. Save. Optionally add the template to forms (Customize entity → Forms) to expose the Associated Record Team Members control pre-bound to that template.

(MS guidance: create templates in Settings → Templates → Access team templates; only a small number of templates per entity allowed.) :contentReference[oaicite:4]{index=4}

6. Adding Access Team controls to entity forms & subgrids

Add the Associated Record Team Members subgrid (or the access team template control) to the main form so users can add/remove users from that record’s access team. When used with an auto-created access team template, the control will automatically create and maintain the per-record access team.

(Practical steps are available in MS docs and community walkthroughs showing the subgrid configuration.) :contentReference[oaicite:5]{index=5}

7. Programmatic scenarios (Dataverse / SDK / Web API)

Common programmatic tasks:

• Create / read TeamTemplate using the teamtemplate table/entity (Dataverse table: TeamTemplate) to manage templates. :contentReference[oaicite:6]{index=6}
• Add a user to an Access Team — for manual teams: create a teammembership or teammember record linking the user to the team; for auto-created access teams, use the Associated Record Team Members control API messages or add accessteam membership entries for the record’s team.
• Share a record via Web API / SDK — you can call the GrantAccess message (SDK) or use the Web API to share a record with a principal (user/team) and specify the access rights (Read/Write/Append/etc.). When auto-created access teams are used, the platform creates the team and adds the shared access automatically for new members added via the form control.

Example: Grant access via Web API (pseudocode)

// Example pseudocode for GrantAccess via Web API (C# / JS SDK patterns exist)
POST [OrgURI]/api/data/v9.2/GrantAccess
Body:
{
  "Target": { "@odata.type": "Microsoft.Dynamics.CRM.account", "accountid": "GUID-of-record" },
  "PrincipalAccess": {
    "Principal": { "@odata.type": "Microsoft.Dynamics.CRM.team", "teamid": "GUID-of-access-team" },
    "AccessMask": "ReadAccess, WriteAccess, AppendAccess"
  }
}
    

(Use the GrantAccess / RevokeAccess SDK messages or Web API equivalent. Also see TeamTemplate entity for programmatic creation.) :contentReference[oaicite:7]{index=7}

8. Limits and important configuration settings

• Templates per entity limit: historically small — typically 2 templates per entity in some on-premises versions or environment settings; check your platform version. :contentReference[oaicite:8]{index=8}
• Auto-created teams per entity / deployment: there are deployment settings (MaxAutoCreatedAccessTeamsPerEntity, MaxEntitiesEnabledForAutoCreatedAccessTeams) that control how many templates/entities can use auto-created access teams; defaults exist and can be changed by admins. :contentReference[oaicite:9]{index=9}
• Performance note: sharing (especially many shared entries) increases the number of security entries (principal-object-access rows) — at scale, sharing can affect performance and storage for the security-sharing table. Consider owner teams or role-based access for high-volume scenarios.

9. Security considerations & best practices

1. Prefer access teams for dynamic collaboration: when membership changes frequently and ownership should remain stable.
2. Use owner teams when you need team-based security roles or team ownership of records.
3. Minimize excessive sharing: large numbers of shared entries (P-O-A rows) can slow queries and increase maintenance complexity; perform periodic cleanup or consider alternate models for large-scale sharing.
4. Limit templates per entity and be deliberate: maintain a small set of templates with clear names and documented access masks (e.g., Account – ReadOnly Team / Account – ReadWriteShare Team).
5. Document UI controls: ensure forms include the associated-record-team-members control in intuitive places and include in user training that adding someone to this subgrid grants record-level access.

(These practices follow platform security model guidance and community experience.) :contentReference[oaicite:10]{index=10}

10. Troubleshooting & common pitfalls

• Access Team not auto-creating: Ensure the entity has Access Teams enabled, template exists, and the Associated Record Team Members control is present on the form. Also check MaxAutoCreatedAccessTeamsPerEntity setting.
• User still can’t see record: Verify the team was granted the correct access rights in the template and the user has not been blocked by business unit or a conflicting security model. Remember that team access is combined with user security roles.
• Too many POA entries: Consider if owner teams or role-based access would better fit high-volume scenarios.
• Converting owner team to access team: On-premises allows converting an owner team to an access team (one-way) — conversion can delete associated resources like queues/mailboxes; validate before converting. :contentReference[oaicite:11]{index=11}

11. Short practical examples

Scenario A — Case collaboration

Add an Access Team Template for the Case (incident) entity with Read/Write/Share. Add the Associated Record Team Members control on the Case form. When a case requires subject-matter experts, the case owner opens the subgrid and adds subject experts — the system creates a per-case access team and grants the configured rights.

Scenario B — Account read-only auditors

Create a template for Account with only Read access. Use it for periodic audit teams who must view but not change the account.

Tip: always validate behavior in a sandbox or test environment before changing production security settings.