AD group teams are not managed exactly the same way “native” teams are managed in CDS, and one difference seems to be that associate/disassociate events will not be triggered for such teams.
However, this does not mean there is no way to respond to a change in the group membership, it just has to be done differently. Quite differently, actually.
With a security group in Azure, we can use graph API to subscribe to various notifications:
Why us there an Azure Function on this diagram? This is because, when creating a subscription, we need to use a webhook that responds in a certain way to the initial validation request (as per the link above):
The client must provide a response with the following characteristics within 10 seconds:
- A 200 (OK) status code.
- The content type must be
- The body must include the validation token provided by Microsoft Graph
Not sure if this would be doable with the Flow only, so, instead, there is an Azure Function and a Flow.
To start with, you will need an HTTP trigger azure function. You’ll find the one I used for this post on github here:
Before you deploy it in Azure, make sure to update FlowUrl variable – it should be pointing to your own Flow:
Which means you will need to create a Flow first.
Here is how my Flow looks like:
There is no JSON parsing in the HTTP request, since I wanted to make sure I see what’s coming in even if the parsing fails. Instead, there is a Parse JSON action.
You can use the payload sample below to generate schema for that action:
The interesting part about this payload is that Graph notifications are cumulative. For those users which were removed from the AD group, you’ll see “@removed”:”deleted”. For the users added to the group, you won’t have that flag.
For the loop, here is what I did:
That “Condition” in the middle is looking at whether “@removed” flag is present in the array element:
If it’s there, the user has been removed. If it’s not there, the user has been added.
How do we match AD user to the CDS user, though?
This is what “List records” action will be doing:
Keeping in mind the json payload sample above, it just need to use the following expression for the “id” parameters:
That’s it for the Flow – once you’ve created it, you will have a url you can, then, add to the Azure Function so it knows how to call the Flow.
The function will just read request body (which is the original notification payload), and it will forward it to the Flow:
Now, once the function has been updated to have correct Flow url, you can deploy it in Azure.
And what’s left is to actually set up Graph notification.
There is a graph explorer tool you can use to work with Graph API:
In order to register the subscription, you’ll need to send this kind of request:
There are a few things to keep in mind there.
For the resource url, you’ll need to use active directory ID of the group you want to start getting notifications for.
For the notificaiton url, you will need to use the url of your Azure Function
Expiration date time can’t be set too far in the future (I think it can only be as far as 48 hours ahead). One piece of the puzzle which I am not describing in this post is how to renew those subscriptions automatically. That’s another request to the graph API, and it can be done with Flows, too, but you’ll need to set up an application in azure, grant permissions, then use HTTP request with OAuth etc.
Anyway, once the notification is there, you might try adding/removing users to/from the Azure group, and, as a result, you should see your Flow responding to the notifications. In the example below, I’ve removed one user from the group:
And I’ve also added another user to the same group. Both changed were packaged into a single notification, so there was one Flow call with two array elements in the json payload, and here is the second one of those two:
Hope this helps!