Table of Contents
When to Use Group.Read.All and When to Use GroupMember.Read.All
As you consider the Graph permissions to assign to an app that processes Entra ID groups, you might be tempted to include both the Group.Read.All and GroupMember.Read.All permissions. On the surface, it seems logical that Group.Read.All is required to read properties of the group while GroupMember.Read.All (Figure 1) is needed to read owner and member information for a group. Well, that’s not quite right and the situation is different if using delegated or application permissions, which is why so many might be confused.

Access to Information with Delegated Group.Read.All
The delegated Group.Read.All permission allows a signed-in user to read information for any group that they have access to, including access granted by holding an Entra ID administrator role such as Groups administrator. However, the permission also grants access to the resources of any group that the signed-in user is a member of. Or as the documentation puts it, “Group.* permissions grant the app access to the contents of the group.”
For a Microsoft 365 group, the contents or set of resources includes the membership, ownership, files in the group’s SharePoint site, team artifacts if the group is team-enabled, the group calendar and conversation threads stored in the group mailbox. This is expected because a core principle of Microsoft 365 groups is that members share full access to all group resources.
For example, signed into in an interactive session, we can use the delegated Group.Read.All permission to retrieve details of a group (that the signed-in user can access) followed by the first conversation from the Inbox folder in the group mailbox:
$Group = Get-MgGroup -Filter "displayName eq 'Ultimate Guide to Office 365'"
[array]$Conversation = Get-MgGroupConversation -GroupId $Group.Id -Top 1
$Conversation | Format-List Id, LastDeliveredDateTime, Preview, UniqueSenders
Id : AAQkADk4ZGQzZTFjLTgyNWMtNDE4Ny04ODg5LWRmZjc2Njg0MDdkOQAQAN-EnW00I29EvD6MbDS93IQ=
LastDeliveredDateTime : 27/01/2026 17:32:27
Preview : Chapter 14, "Managing Application Idle Timeout Periods"
Reply in Microsoft Planner
You can also reply to this email to add a task comment.
This task is in the MAC Tasks plan.
UniqueSenders : {Michel de Rooij (MVP)}
The Group.Read.All permission allows access to files in a group’s SharePoint site using the Get-MgGroupDriveItemChild cmdlet. This example finds the default document library for the site and retrieves details of the items in the root folder of the document library.
Get-MgGroupDefaultDrive -GroupId $Group.Id $Root = Get-MgGroupDriveRoot -GroupId $Group.Id -DriveId $Drive.Id [array]$Items = Get-MgGroupDriveItemChild -GroupId $Group.Id -DriveId $Drive.Id -DriveItemId $Root.Id -All
Groups can have plan resources, but Planner does not allow access to plans via delegated Group.Read.All. This is because access to Planner is not authorized by group permissions. A separate set of Task permissions controls access to plans and tasks.
Application Permission Even More Powerful
Because the application Group.Read.All permission enables access to all Entra ID groups, it is a high-profile permission whose assignment to apps should be restricted to when absolutely necessary. Controlled assignment and monitoring are more important for the even more powerful Group.ReadWrite.All permission. Note that the Group.Read.All application permission does not grant access to a group calendar. Only delegated access is supported for group calendars.
The Least Permissioned Nature of GroupMember.Read.All
Which brings me to the GroupMember.Read.All permission. This is not an additive permission to Group.Read.All because the combination delivers precisely nothing extra in terms of access to group data. Remember, Group.Read.All can access group membership and ownership information.
The role of the GroupMember.Read.All permission is to facilitate access to basic group information such as the group identifier and display name, together with the membership (members and owners), including transitive membership.
GroupMember.Read.All grants no access to group resources. As such, GroupMember.Read.All is a least-privilege alternate to Group.Read.All in both delegated and application scenarios and is the right permission to assign to apps and scripts that only need to report or audit group membership, or answer questions like “what groups is this user a member or owner of?”
Fetching User Information
One last thing. GroupMember.Read.All is sufficient to retrieve the membership or ownership of a group. The response is a set of account identifiers, like this:
[array]$Members = Get-MgGroup -GroupId $Group.Id $Members Id DeletedDateTime -- --------------- 0baa2d94-c5d6-4e9e-9fe6-7a2fefd50f42 2d30cc10-234e-47aa-a441-9175c8917775 2e333619-44af-47c1-ad4d-cfc4b7218e70
As you probably know, to get details of the accounts, you can fetch data like display names and email addresses from the special additionalProperties property. This allows apps to do things like list the display names of group members:
$Members.additionalProperties.displayName Tony Redmond Paul Robichaux (Office 365 for IT Pros) Vasil Michev (Technical Guru)
However, if the app doesn’t have at least the User.ReadBasic.All permission, you’ll see something like this:
$Members.additionalProperties
Key Value
--- -----
@odata.type #microsoft.graph.user
businessPhones {}
@odata.type #microsoft.graph.user
businessPhones {}
@odata.type #microsoft.graph.user
businessPhones {}
Nothing is wrong. It’s just that the app doesn’t have permission to read user account properties. If you assign the necessary permission, the data returned will include the missing information:
Key Value
--- -----
@odata.type #microsoft.graph.user
businessPhones {}
displayName Paul Robichaux (Office 365 for IT Pros)
givenName Paul
mail Paul.Robichaux@office365itpros.com
surname Robichaux
userPrincipalName Paul.Robichaux@office365itpros.com
In Conclusion
The rules for assigning Group permission are:
- Use GroupMember.Read.All whenever an app only needs access to basic group details and group membership information.
- Use Group.Read.All when an app needs access to group information, including properties, membership, and resources.
- Include User.ReadBasic.All or User.Read.All to retrieve full details of group members or owners.
- Always start with the least privileged permission and progress to a higher-level permission only when necessary.
It took me a while to get my head around this structure, but it does make sense when you think about how the Graph retrieves data based on granular permissions.
Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.