List M365 Group owners with Graph API query parameters
I use the Graph API a lot in Power Automate. Today I want to point out how powerful the usage of query parameters can be. This article demonstrates how you can list all the e-mail addresses of owners of a Microsoft 365 Group with one action.
Inspiration
This tweet from Tom Riha:
Do you need owners of a M365 group (= modern #SharePoint site) in your #PowerAutomate flow? Graph API is (again) the answer! https://t.co/zzcjF5eAKz#PowerPlatform #MicrosoftFlow #PowerAddicts
— Tom Riha | Microsoft MVP (@riha_tom) June 12, 2022
Like always this was a great blog about listing Microsoft 365 Group owners with some great techniques and tricks in it. Tom has a lot of great content about Power Automate on his site, definitely check it out.
Graph API Query parameters
When I was testing Tom’s solution I thought I might be able to simplify things by using Graph API query parameters.
The Graph API supports things like $select, $filter & $expand. And this was exactly what we were doing in the original flow.
But before you get all excited. Not every query parameter is supported for every resource type or method.
Always check before you start building your query. In this instance we would be interested in the List Groups method. Luckily this method supports $select, $filter & $expand.
Flow setup
In this example we are trying to retrieve the list of e-mail addresses of owners of the IT group. We are using a $filter on the displayName. With an $expand we are retrieving the owners. And with a nested $select we are retrieving the mail property of the owners.
1. Add a Manually trigger a flow action.
2. Add a Send an HTTP request (Office 365 Groups Connector)
Note: the question mark character after the groups needs to be escaped with a forward slash character. This is a small gotcha for this specific action. In actions like HTTP this is not needed.
a. Use a the URI below:
b. Select the GET method
That is it for the setup of this example. The response of the action should look something like below.
Happy testing!
Ello, Eliot here from the community. I’m actually working on this and had got here separately (I have another call that will help – see later), and I wondered if I could filter by a second level. I wanted to find the owners of all sites in SharePoint, so went around the houses on this one, and I came to the conclusion that it was actually better to approach the users endpoint. I forget why. Anyway, that call eventually got built in to the workable: >>>GET https://graph.microsoft.com/v1.0/users/?$expand=ownedObjects($filter=proxyAddresses/any(p:startsWith(p, ‘SPO:’)))<<< the thing is that I still return users that are irrelevant. I would prefer not to. I can work with that call, but if I can offload my logic into that, it would be more streamlined. The same must be possible on the groups endpoint, too.
Sorry, you need to filter by the proxyAddresses because you can still remove a SharePoint site from a group, or have a 365 group without a team site, I believe. This will also, though, handily provide the SharePoint site ID for the site. So if you ever wish to email a user about their site, you can extract that id from the proxyAddresses, it’ll be the first one, and any hubs you will be able to use the second ID.