Track User Changes with Graph API in Microsoft Power Automate
12/07/2024
OfficeLabs have recently experimented with Graph API in Microsoft Power Automate, and we’ve learnt a lot. Graph API is an efficient and powerful tool, accessing Microsoft’s cloud services and data – in this case, Azure Active Directory.
This article takes a deep dive into what Graph API is, the nodes available, how OfficeLabs used them in real-life situations, and how additional nodes can be used to create an all-encompassing, hands-off joiners, leavers and movers (JML) process.
If you’re interested in reading about OfficeLabs’ existing JML process, take a look at our solutions page.
Create User
Information submitted through the JML application creates a user before their starting date.
Add Member to Group
Grants access to a specific security or M365 group when they are starting their role at the organisation.
Message in a Channel
Send a welcome message in a group channel let the team know there’s a new starter.
Update User
Uses updated information submitted through the JML application to update user details.
Change Group
If an employee is moving roles and department, change the security or M365 groups they should be part of.
Delete User
Following an approval process, a user can be deleted from AAD once their contract or notice period is completed.
Remove From Group
Revoke access to a security or M365 group when they no longer require membership.
Logout User
Once an employee has left, force all devices to log out of their Microsoft 365 account before deleting user.
What is Microsoft Graph API and Delta Queries?
Microsoft Graph API allows developers to view and interact with resources in a tenancy using HTTP queries. This applies across a range of Microsoft services such as Teams, SharePoint, Planner, Outlook, 365 and Security groups, as well as Azure Active Directory.
Delta Queries are a key method of efficiently tracking changes to resources in a tenancy. In our solution, Delta queries are used to track user attribute (last name, job title, line manager) changes in AAD.
So, how did we do it?
- Initial Query
A GET request is made to AAD using the HTTP Request action in Microsoft Power Automate; this can include a ‘$select’ to limit the amount of information being retrieved. Depending on how large your set of data is, you may receive a ‘Next Link’.
Next Links are used to breakdown your retrieved data into manageable, digestible ‘chunks’. Using the Next Link, this step can be looped through repeatedly until a Delta Link is provided in the outputs. This indicates that the ‘historical’ end point has been reached. This means the Delta Link can be used to retrieve any and all changes that have occurred since the previous Delta Link was used.
- Storing the Delta Link:
We obviously don’t want to run through this loop towards Delta Links every time the workflow triggers. Choosing a safe, secure and version-controlled data repository is the best way of maintaining, and updating, the Delta Link.
- Creating a Change Log:
The final step is to create a SharePoint List, ‘AAD Change Log’, that stores the array returned by the workflow. In OUR case, we are storing changes the last name, job title, department, line manager and mobile phone number. In YOUR case, you can store whatever attributes you like!
And that’s it… But how could we expand upon this process?
You could send emails or Teams notifications to HR as a confirmation that changes have been registered in Azure Active Directory. There’s the potential to create reports in Power BI for HR or IT teams to analyse user change requests, better understanding where the most user changes occur. Or even integrate Graph API into a fully-fledged Joiners, Leavers and Movers solution, like OfficeLabs have.
What Benefits Were Realised?
The list could go on, but if you’d like to have a complete overview of the solution, get in contact with OfficeLabs to book in a demo.
