Why this matters
Identity and groups are the foundation of access in Microsoft 365. Every workspace, every permission decision, and every collaboration boundary is ultimately expressed in terms of who is in which group. Getting the vocabulary right — and choosing the right tool for the right job — prevents a lot of the rework that shows up after a deployment is in flight.
Identity types at a glance
| Identity type | What it is | Use it for |
|---|---|---|
| User identity | Individual identity with sign-in, mailbox, and OneDrive. | Every employee, contractor, or guest who needs to access M365 resources. |
| Microsoft 365 Group | Collaboration identity with Owners and Members. Backs Teams, group-connected SharePoint sites, group mailbox, Planner. | Project workspaces, departments, communities — wherever collaboration is the goal. |
| Security Group | Identity used to control access. No mailbox, no collaboration features. Can include users, groups, and service principals. | Access control across SharePoint, files, applications, and conditional access policies. |
| Mail-Enabled Security Group | Security group with an email address. Can be used both for access control and for email distribution. | Notifications, workflow approvers, compliance targeting where the same group needs to be addressable by email. |
| Distribution List | Email distribution only. No permissions, no access control. | One-way mailings to large groups (newsletters, broadcasts). Increasingly being replaced by M365 Groups. |
Microsoft 365 Groups in detail
Microsoft 365 Groups are the membership service that underpins most collaboration in M365. When a group is created, several resources are automatically provisioned at the same time. Some are unavoidable; others are optional and only created when explicitly enabled.
Automatically created with every M365 Group:
-
Group identity. A shared identity in Microsoft Entra ID with Owners and Members.
-
Group mailbox and calendar. A shared Outlook mailbox and calendar — created even if the group never uses them.
-
Group-connected SharePoint site. Provisioned asynchronously. Exists even if 'unused.'
-
OneNote notebook. A shared notebook tied to the group's site.
Optionally created (must be explicitly enabled):
-
Microsoft Teams. A Group does not automatically create a Team. Creating a Team will, however, create or use an underlying Group.
-
Planner. Plans require a Group, but a Group does not auto-create a Plan.
-
Viva Engage community. Optionally connected to a Group.
-
Power BI workspace. Optionally connected to a Group.
Every Group-connected workspace gets a mailbox and a SharePoint site whether it uses them or not. Over the years this is one of the larger sources of governance debt — orphan mailboxes, orphan sites, and unused Planner plans. Group-connected sites should be created intentionally, not as a default for every collaboration need.
Group-connected vs. Group-less sites
SharePoint Team Sites can be created with or without a Microsoft 365 Group. The distinction matters because the two are governed and used differently.
| Group-connected Team Site | Team Site (no Group) |
|---|---|
| Backed by an M365 Group with shared Owners and Members. | Standalone site with SharePoint groups (Owners, Members, Visitors) and SharePoint permission levels. |
| Provisions a mailbox, OneNote, Planner, and optionally Teams. | No mailbox, no Planner, no Teams. |
| Membership = Group membership; changes everywhere at once. | Permissions managed per-site, more granular control. |
| Best for active collaboration where chat, files, and tasks belong together. | Best for departmental, operational, or long-running content where a Team isn't appropriate. |
| Simplified two-tier access (Owners / Members). | Three-tier access (Owners / Members / Visitors), with finer-grained permission levels. |
Whether group-connected sites are the default for collaboration in your organization is a platform-level decision. Group-connected sites are simpler and faster to spin up, but they carry baggage (mailboxes, Teams pressure) that group-less sites don't. Many organizations default to group-less for departmental and operational sites, and use group-connected sites only for active project workspaces where Teams will actually be used.
Kybera Impact separates these into distinct workspace templates with different defaults: group-connected Teams workspaces for active collaboration (with lifecycle policies attached), and group-less Team Sites for departmental and operational content. The Workspaces module provisions the right shape based on the template chosen at request time, so the decision happens once at request approval rather than being negotiated for every new site.
Static vs. dynamic membership
Group membership can be managed manually (static) or automatically based on user attributes (dynamic). Both are supported for Microsoft 365 Groups and Security Groups in Microsoft Entra ID.
| Static | Dynamic | |
|---|---|---|
| How it works | Members are added and removed manually by an owner or admin. | Membership is automatically calculated from rules based on user attributes (department, role, location, etc.). |
| Best for | Small or specialized groups; project teams; situations where attribution isn't clean. | Department-wide groups, role-based access, large groups that change frequently. |
| Maintenance | Requires a person to manage. Drifts out of sync over time. | Updates automatically as user data changes. Stays accurate as long as source attributes are accurate. |
| Risk | Membership accuracy decays without active stewardship. | A bad attribute (e.g., 'Department' typo) silently changes membership. Requires good HR data. |
| Licensing note | Available on standard licenses. | Requires Microsoft Entra ID P1 (Azure AD Premium P1). |
Use dynamic membership wherever the rule is clean and the source attributes are reliable — department, location, employee type. Use static membership for committees, project teams, and any group whose composition isn't expressible as an HR attribute.
Group naming and creation governance
Two governance levers are worth deciding on early because they apply tenant-wide and are expensive to retrofit:
-
Group creation restriction. By default, any user can create a Microsoft 365 Group (and therefore a Teams workspace, a SharePoint site, and a Planner plan). Most organizations restrict group creation to a defined set of users via a security group, with self-service requests routed through a provisioning workflow.
-
Group naming policy. A naming policy applies a consistent prefix or suffix to every Group, which keeps the tenant directory orderly. Naming policies also support blocked-words lists to prevent inappropriate or confusing names.
Group creation is restricted at the tenant level, and all new workspaces are created through the Kybera Impact request flow. The flow captures the workspace template, business authority, purpose, and owners, then provisions everything (Group, site, Team if requested, libraries) from a defined template — applying naming standards, hub association, and property bags automatically.
This shifts the question from 'how do we stop end users from creating groups?' to 'how do we make the request experience fast enough that users prefer it?' — typically minutes, not days.
Discussion Questions
• Do we want group-connected sites as the default for collaboration, or group-less sites?
• Where do we want sites that are not group-connected — departments, operational areas, sensitive content?
• Are we comfortable with the simplified Owners/Members model for project workspaces, or do we need three-tier permissions everywhere?
• Do we expect collaboration spaces to start in SharePoint and remain there, or to evolve into Teams over time?
• Should Planner be a default tool, or used selectively?
• Do we want to restrict group creation? Who's allowed to create new groups directly?
• Do we want a group naming policy? What prefix/suffix scheme reflects how we organize the tenant?
• Where can dynamic membership replace manual maintenance? What attributes are reliable enough to drive it?