Power Automate: list users in nested groups

Key insights

• List group members returns direct members, which can be groups rather than the people inside them.
• The transitiveMembers endpoint resolves membership through nested groups.
• Add /microsoft.graph.user to return user objects instead of nested groups.
• The demonstration uses Send an HTTP Request from the Office 365 Groups connector.
• The transcript identifies GroupMember.Read.All as the permission discussed.

Power Automate can retrieve users across nested Microsoft Entra ID groups by calling Microsoft Graph’s transitiveMembers endpoint, avoiding a flow that repeatedly explores child groups. This approach matters to flow makers and administrators who need a user list from a group whose membership includes other groups. Pragmatic Works demonstrates the request with the Office 365 Groups connector and a sample security group.

What it does

The standard List group members action returns direct members. If a parent group contains two child groups, the action returns those groups; it does not by itself provide the users nested inside them. A flow that relies on the action alone can therefore stop at the first level of group membership.

Microsoft Graph offers a transitive membership query for following membership through nested groups. The endpoint used in the demonstration is . Adding filters the returned objects to users, so the result does not include group objects as entries in the user list.

That distinction can simplify a flow. Instead of adding repeated loops and additional calls for each subgroup, the flow requests transitive members from Graph and then transforms the returned users. In the example, a Select action keeps each person’s display name. Other fields shown in the response include a user principal name, email, job title, given name, and ID.

Who it is for and what you need

This technique is for makers building cloud flows that need a full user list from a group hierarchy, including users in child groups several levels down. It can help when a process needs names or profile details from the group, but the demonstration does not describe a specific business process or prescribe how the resulting list must be used.

You need the group’s ID, shown in the flow as the group ID or GUID, and a way for the flow to make the Microsoft Graph request. The demonstration uses the Send an HTTP Request action in the Office 365 Groups connector. It also identifies as the permission for reading group members and says the permission is supported for work or school accounts and application users, but not personal Microsoft accounts.

The video does not specify a required Power Automate plan, tenant rollout stage, or regional availability. It also does not explain the tenant’s consent or connection setup for the permission. Confirm the authentication method and required consent with your organization’s administrators before using the request.

How it works

1. Start with the group you want to inspect and obtain its group ID. In the demonstration, the flow uses a manually triggered flow and the sample Lawyers group.
2. Add Send an HTTP Request from the Office 365 Groups connector. Configure a GET request to the Microsoft Graph transitive-members endpoint for that group: .
3. Use the user type cast at the end of the endpoint to return user objects rather than the nested groups. The demonstration also sets the content type to .
4. Pass the response to a Select action and map the fields the next step needs. The example maps , producing a readable list of five people from the nested sample groups.

The sample structure has three group levels: Lawyers contains state groups, which in turn contain practice-area groups and users. Some users are directly inside a lower-level group, while others are inside further nested groups. The transitive query returns the five individual users without requiring the flow maker to construct another loop for each layer.

The endpoint can also be adjusted for other results. The demonstration describes changing the type cast to to retrieve groups, or omitting the cast to return both users and groups. It also mentions optional query parameters: , , , , and .

Limitations and open questions

The sample establishes the basic query and demonstrates the result, but it is not a complete production flow design. The transcript does not show how to handle every possible response condition, such as a failed request, or how to store and use the list after the Select action. Plan and test those parts for your own flow rather than assuming the sample covers them.

Microsoft Graph responses can involve optional parameters and constraints. The demonstration notes that search applies to display name or description, not email or ID, and points out that maximum page sizes exist. It does not show a complete pagination implementation or explain how to process a next-page link, so do not assume the sample’s single displayed response is sufficient for every group size.

The previous approach—repeating List group members for each subgroup—requires the flow to anticipate how many levels to traverse. A new subgroup can make that fixed-depth design incomplete. The transitive endpoint avoids manually encoding that traversal, but the right permission, connection configuration, response handling, and query options still need to be checked for the target environment.

Sources

• Microsoft Graph transitive users query with selected fields
• Microsoft Graph transitive members filtered to users
• Pragmatic Works Power Automate demonstration

Frequently asked questions

How do I get users from nested groups in Power Automate?

Call Microsoft Graph's /groups/{group-id}/transitiveMembers/microsoft.graph.user endpoint using an HTTP request action. The user cast filters the results to user objects.

Why does List group members not return everyone in nested groups?

It returns direct members. If those members are groups, the action returns the group objects rather than automatically listing the users inside those groups.

What permission does the nested membership example use?

The demonstration identifies GroupMember.Read.All. It says this permission is supported for work or school accounts and application users, but not personal Microsoft accounts.

Can I return groups as well as users?

The demonstration says to change the type cast to microsoft.graph.group for groups, or remove the cast to return both. It does not provide a full pagination implementation.