Teams and team types

What it does

A team groups users so they can hold roles or receive shared rows collectively. Dataverse has owner teams, access teams, and Microsoft Entra group teams (security group or Office group flavours). A team belongs to one business unit but can contain users from several.

Key facts

Owner teams own rows and have security roles assigned. Members are added manually. The team has full access rights to what it owns.
Access teams own nothing and have no roles. Rows are shared with the team and members get the granted rights — Read, Write, Append and so on. They're the more performant sharing mechanism because they can't own or hold roles.
Entra group teams own rows and hold roles like owner teams, but membership is derived dynamically from the Entra group when a member accesses the environment. Membership is managed in Entra, not in Dataverse.
The environment picker only recognises users who are members of Entra group teams or who have roles assigned directly. That's a real constraint on how users find the environment.
Access teams come in two forms: user-created (share many rows with one team) and system-managed (created per row from a team template). A system-managed team belongs to its one row.
Team templates define the table and the access rights granted, and appear as a list on the row form. The actual team is created when you add the first member. Changing a template only affects new teams, not existing ones.
Only tables enabled for system-managed access teams can be named in a template — that's the Have an access team property on the table.
To add or remove someone from an owner team you need at least the privileges the team holds. Adding a member to a team with System Customizer requires System Customizer or System Administrator yourself.
Owner teams can be converted to access teams, one way only. All owned rows must be reassigned first, and the team's role assignments are removed in the process. Entra group teams and access teams can't be converted.
Disabled users can't be added to owner teams unless AllowDisabledUsersAddedToOwnerTeams is set.
Team membership changes via plug-in must run asynchronously.

When to use / skip

Entra group teams are the default answer for granting access at scale — membership follows the directory, joiners and leavers handle themselves, and there's no Dataverse-side admin. Use owner teams when rows genuinely need to be owned by a group rather than an individual, typically a queue-like workload where anyone in the team picks up the work. Use access teams for exceptions: a specific deal that three people outside the normal boundary need to see. Reach for system-managed access teams when that exception pattern is routine and per-row — a case team, a bid team — because it's far cheaper than sharing rows individually. Skip access teams as a general access mechanism; they're a scalpel, and using them broadly recreates all the problems of ad-hoc sharing.

Configuration decisions

Entra group teams versus owner teams as the default role-assignment mechanism, which is really a question of whether the client's directory hygiene is good enough.
Which business unit each team belongs to, since that scopes the roles it can usefully hold.
Privilege inheritance on any role assigned to a team — team privileges only, or team plus direct user access.
Whether access teams are user-created or template-driven, and which tables get access team templates.
Who administers membership, and whether the Administrator field is backed by an actual plug-in enforcing it.

Gotchas

The Administrator field on a team is decorative. It does nothing unless somebody registers a plug-in on AddMembersTeam to enforce it, which almost nobody does.
Entra group team membership resolves when the user accesses the environment, not when the group changes. A user added in Entra can appear to have no access until they try.
Owner-to-access conversion is permanent and strips the roles. Business unit default teams converted this way can never own rows again.
The privilege requirement for managing owner team membership surprises delegated admins — they can't add someone to a team more privileged than themselves.
Changing an access team template doesn't retrofit existing teams. You'll have two generations of access rights on the same table and no obvious way to tell them apart.
Rows imported without an owner get a default role assigned to the team record — Salesperson in a Sales environment, Basic User elsewhere. Worth knowing before you audit a post-migration environment.

Consultant notes

Standardise on Entra group teams and say so in the design. It removes an entire category of ongoing admin and it's the pattern Microsoft's own business unit guidance is built around.
Warn that the environment picker only sees direct role assignments and Entra group team membership. Roles granted through plain owner teams leave users unable to find the environment, which looks like a licensing problem and isn't.
Get the joiners/movers/leavers process documented against team membership. It's the control that auditors ask about and the one nobody has written down.
If the client wants "the case team can edit the case", that's a system-managed access team with a template, not a new business unit. It's a much cheaper answer and worth offering unprompted.

Worth another look if Entra group team membership resolution changes, or if team conversion becomes reversible.