Business units group people by where they sit in the org chart. Security roles define what a job function is generally allowed to do. Teams solve a different problem: access that needs to follow a group of people who don't map cleanly to either one.

A cross-functional project, a shared pool of accounts, a handful of people who need into one specific record — Dynamics 365 CE gives you two distinct kinds of team for this, and picking the right one matters.

Quick facts
  • Owner teams can own records directly and hold their own security roles
  • Access teams own nothing, carry no role, and target one record at a time
  • Access teams are often spun up automatically via an access team template
  • A user's effective access can come from their own role and a team's role at once

Owner teams: a shared inbox instead of one person's

An owner team can own records directly, exactly the way an individual user can. A record doesn't have to belong to "Sarah" or "James" — it can belong to the team itself, with every member sharing responsibility for it.

This is the Dynamics 365 CE equivalent of a shared department mailbox: the whole team can open it and work from it, and nobody's out of the loop just because one person is on vacation.

Owner teams can also be assigned their own security roles, on top of whatever roles their individual members already hold. A team member's real, effective access on a shared record can come partly from their personal role and partly from the team's role — both apply.

Access teams: temporarily added to one project folder

An access team is much lighter-weight. It doesn't own anything, and it carries no security role at all. All it does is grant a specific group of people access to one particular record, for as long as that access team is attached to it.

The closest everyday parallel: temporarily adding a few colleagues to a shared project folder for the duration of just that one project. They get in, they can do what the folder's permissions allow, and it has no effect on anything outside that folder.

In practice, access teams are frequently spun up automatically through an "access team template" tied to a table — one project folder, freshly labeled, ready the moment a new record is created.

Owner teamAccess team
Can own records directlyYesNo
Can be assigned a security roleYesNo
Typical scopeOngoing shared responsibility across many recordsOne specific record, for as long as it's needed
Everyday parallelA shared department mailboxBeing added to one project's shared folder
Example A company creates a "Regional Sales" owner team to hold Accounts that belong to the region as a whole rather than any one rep — new leads land there until someone claims them. Separately, when a high-value Opportunity needs input from a solutions engineer outside the usual sales team, an access team gives that one engineer access to that one Opportunity only, without folding them into Regional Sales or changing their security role at all.

Roles define capability, teams define ownership and access

Keep the boundary clear: a security role answers "what is this kind of user generally allowed to do across a table?" A team answers a narrower question — "who owns this batch of records, or who needs into this one record right now?"

Teams don't replace security roles; they sit alongside them, modeling shared responsibility and one-off access that a business-unit-and-role structure alone can't express cleanly.

Key takeaway: Owner teams can own records directly and hold their own security roles, making them a good fit for shared, ongoing responsibility — like a shared mailbox. Access teams own nothing and carry no role; they simply add a specific group of people to one specific record, like a temporary addition to a project folder. Security roles define general capability; teams define specific ownership and access.