What it does

Dataverse decides who can see a case through four mechanisms: the owner, the owning business unit, team membership, and row-level shares. Owner teams own records and carry security roles. Access teams own nothing, carry no roles, and exist only to grant specific rights on specific records.

Key facts

• Owner teams own rows and are assigned security roles. Access teams do neither — members get their privileges from their own roles and the access rights the team grants.
• Access teams come in two flavours: user-created (works across multiple records, managed with AddMembersTeamRequest) and auto-created from a team template (scoped to one record, managed with AddUserToRecordTeamRequest).
• Auto-created access teams need a team template that names the table and the rights granted. The team is created the moment the first user is added to that record's team subgrid.
• Default limits are MaxAutoCreatedAccessTeamsPerEntity at 4 and MaxEntitiesEnabledForAutoCreatedAccessTeams at 100. Both are environment database settings, changed with the OrganizationSettingsEditor.
• Editing the rights on a team template only affects teams created after the change. Existing auto-created teams keep the rights they were born with.
• Team membership never grants Create. A user needs Create on the table through their own security role, at some level, or nothing they can do with the team matters.
• Access team rights are capped by the user's own privileges — a team granting Delete on Case does nothing for a user whose role has no Delete privilege.
• Every share, every access team member and every cascaded share writes rows to PrincipalObjectAccess. That table is the usual cause of a service environment's storage and performance going sideways.
• "Set whether reassigned records are shared with original owner" defaults to No. Turning it on writes a POA row on every single reassignment.
• Modernised business units add an owning business unit column that's independent of the owner's own business unit, and let you assign a user a security role from a business unit they don't belong to.
• Never delete POA rows directly. Revoke through the security model, and use inherited access rights cleanup after changing a cascade configuration.

When to use / skip

For most service deployments the answer is: business unit plus owner team, and stop there. Cases are owned by a queue or a team, agents have Business Unit or Parent:Child read on Case, and nobody needs sharing at all.

Reach for auto-created access teams when access is genuinely per-record and unpredictable — a complaints case where a named legal contact and a named account manager get read access to that one case and nothing else. That's a real pattern and access teams handle it cleanly. Reach for modernised business units when a user legitimately works across two service desks; it is a much better answer than the old team-ownership workaround.

Skip access teams if you're using them to model an org chart. That's what owner teams and hierarchy security are for, and access teams will bloat POA doing it badly.

Configuration decisions

• Who owns a case: the agent, an owner team, or a queue — and whether ownership changes on assignment or stays put.
• Whether the security model is business-unit-per-service-desk, or one business unit with team-based separation. This is close to a one-way door once there's data.
• Whether to enable modernised business units and expose the owning business unit column on case forms, with a default set by automation.
• Which relationships cascade Share and Reparent. Case-to-activity cascade is where POA growth usually starts, and Cascade None on the ones you don't need is cheap to set early.
• How many auto-created access team templates you need per table, and whether you're going to have to raise the default of 4.
• Whether reassigned records stay shared with the original owner — a small setting with large POA consequences.

Gotchas

• POA growth is invisible until it isn't. By the time queries are slow you have hundreds of millions of rows and no easy remedy, because you can't just delete them.
• Changing a team template's access rights silently applies to new records only. The client reports "some cases behave differently" and there's nothing in the config to see.
• Access teams don't appear in Advanced Find the way owner teams do, so security testing that relies on views misses them.
• Business unit restructuring after go-live is painful: records carry their owning business unit, and moving users between units changes what they can see in ways that are hard to preview.
• Users assigned a role from another business unit under the modernised model still need the owning business unit column populated correctly, and legacy automation doesn't set it.
• A user who can see a case via an access team but has no Read on the related account gets a half-rendered form and a support ticket about "broken cases".

Consultant notes

• Do the security design workshop before anyone builds a form. Retrofitting a business unit structure onto a live service desk is the single most expensive rework on these projects.
• Tell the client plainly that sharing is not free. "Just share it with them" is the request you should refuse most often.
• Demo access teams with the complaints or VIP-case scenario. It lands immediately, and it stops the client asking for a custom security model.
• Before go-live, run a POA row count and record it. You want a baseline to compare against at three and six months.
• Check cascade settings on every custom relationship you've added to Case. Defaults are generous and nobody reviews them.

---

Worth another look if POA growth accelerates, or before any business unit restructure.