If you've ever managed a SharePoint site, you’ve probably noticed a common gap: there is no built-in alert that tells you when a new user is added to a site group or when permissions are modified. Unless you have tenant-level access to audit logs, these changes can easily go unnoticed.
However, you can build your own monitoring solution using a simple Snapshot and Compare pattern in Power Automate.
Since there is no direct trigger for permission changes, the idea is to use a scheduled flow. Think of it like taking a daily snapshot of your site members and comparing it with the previous snapshot. If there is a difference, the flow sends a notification.
How to Build It
1. Set the Schedule
Start with a Recurrence trigger. Running once per day is usually sufficient, but you can run it more frequently if you need faster detection.
2. Capture the Current State
Use the Send an HTTP request to SharePoint action to retrieve users from site groups.
Example endpoints:
_api/web/sitegroups/getbyname('Members')/users
_api/web/sitegroups/getbyname('Owners')/users
These return the current list of users in each group.
3. Compare Against Your Baseline
You need a place to store the previous snapshot. A simple SharePoint list works well for this.
Retrieve the stored list of users
Compare it with the current API response
You can use a Filter Array action to find users who exist in the current list but not in the stored list. These represent newly added users.
Similarly, you can detect removed users if needed.
4. Send the Alert and Update the Snapshot
If a difference is detected:
Send an email or Teams notification to the intended recipient
Include details such as user name, email, and group (Members or Owners)
After that:
Update your stored snapshot with the latest user list so it is ready for the next run
Why This Approach Works
Visibility
It gives you a practical way to track access changes without needing admin-level audit logs
Flexibility
You can extend it to track removals, multiple groups, or even log changes historically
Simplicity
The logic is straightforward and easy to maintain since it relies on a scheduled check instead of complex triggers
Pro Tip
If your site uses custom group names (for example, "Project Alpha Members"), make sure your API calls use the exact group name, or use the group ID for a more reliable setup.
Summary
No direct trigger exists for SharePoint permission changes
A scheduled comparison-based flow is the most practical solution
You can monitor Members and Owners and notify specific users on changes
✅ If this answer helped resolve your issue, please mark it as Accepted so it can help others with the same problem.
👍 Feel free to Like the post if you found it useful.
