Summary
Security (Entra) groups versus Microsoft 365 groups: which to choose and where they can be used in Microsoft 365.
Microsoft 365 has two different types of groups that can be used to control access to resources: Security groups (formerly called Azure Active Directory, also now called Entra ID) and Microsoft 365 groups.
Structurally, these behave very differently – for example, a Microsoft 365 group comes with a shared mailbox and SharePoint site, and does NOT allow nesting of other groups inside of it, only people.
Security groups are just a group. They DO allow nesting, so for example you could have a “Sales & Marketing” group that has a group for sales and a group for marketing nested under it. Confusingly, you can mail-enable these so that they can also have a mailbox, but that’s less common.
These both allow “dynamic membership rules” in Azure, so you can dynamically assign people with the department value “Sales” to a Sales group and so on. The decision point for the group type comes down to what you intend to use it for, because you can’t use one or the other interchangeably. Some objects in Microsoft 365 won’t allow you to use one or the other for permissions!
Which group type to use where
Generally speaking, if you need a mailbox and a place to store files, a Microsoft 365 group is a good way to go. It also allows your end users to manage their group membership directly from the places that they’re using it (e.g. Outlook). This can be a pro or a con depending on your point of view! Most organizations allow users to create their own Microsoft 365 groups, too, whether they realize it or not, by virtue of leaving the setting “allow self-service site creation” on in SharePoint. Creating a site from SharePoint will automatically create a group as the default behavior, so many people will use this to “skirt” around IT limitations and manage their own groups.
Conversely, certain apps and features ONLY work with Microsoft 365 groups – primarily features that are “groupy”, like Teams and Planner.
Here’s a table to outline which group types work where:
| Feature/Service | Security Groups (Entra) | M365 Groups |
|---|---|---|
| Power BI | ✅ (RLS, access to apps/reports/workspaces) | ✅ apps/reports/workspaces ❌ row-level security |
| SharePoint | ✅ | ✅ |
| Teams | ❌ | ✅ |
| Microsoft Lists | ✅ | ✅ |
| Planner | ❌ | ✅ |
| Microsoft Forms | ❌ | ✅ |
| Power Automate Cloud | ✅ | ✅ |
| Canvas & Model-Driven Power Apps | ✅ | ✅ |
| Dataverse security roles (though you need to create the team in Dataverse and link it to the group) | ✅ | ✅ |
| Copilot Studio Agents | ✅ | ❌ |
| Azure Resource access | ✅ | ❌ |
| Loop | ❌ | ✅ |
This may not sound like a super huge deal, but when you’re trying to promote Microsoft 365 groups as a one-stop-shop solution for a team, and then it just won’t work certain places, it’s awkward. You end up having to maintain the group membership in two different groups. Fingers crossed that eventually we’ll be able to use all group types on all objects, but I’m not holding my breath. 🙂