Why Group Membership Sync Does Not Update SharePoint Access
🔍 WiseChecker

Why Group Membership Sync Does Not Update SharePoint Access

When you add a user to a Microsoft 365 group, you expect that user to gain immediate access to the group’s SharePoint site. In many cases, the access does not appear for hours or even days. This delay happens because SharePoint caches group memberships and does not check for changes in real time. This article explains why the sync delay occurs and what you can do to force an update or work around the limitation.

Key Takeaways: Group Membership Sync in SharePoint

  • SharePoint group membership cache: Stores group member lists for 24 hours by default, causing delayed access for new members.
  • Microsoft 365 group owner vs member: Owners see changes faster because SharePoint treats owner changes as high-priority events.
  • SharePoint admin center > Site permissions > Check permissions: Lets you verify whether a user’s access has been provisioned after a group change.

ADVERTISEMENT

Why SharePoint Does Not Update Access Immediately After a Group Change

SharePoint relies on a cached copy of group memberships rather than querying Azure Active Directory on every page load. This cache is refreshed on a timer. The default refresh interval is 24 hours for most sites. Microsoft 365 group membership changes are not pushed to SharePoint in real time. Instead, SharePoint polls for changes at scheduled intervals.

The delay is by design. Without caching, every page request would require a cross-service lookup, which would slow down site performance. The trade-off is that new group members do not see the site appear in their SharePoint sites list or gain access to site contents until the cache refreshes.

The 24-Hour Cache Window

SharePoint stores group membership data in a local cache called the group membership cache. This cache is updated once every 24 hours by default. If you add a user to a Microsoft 365 group at 10:00 AM, SharePoint may not recognize the user until 10:00 AM the next day. The cache update is not triggered by the group change itself. It runs on a fixed schedule set by the SharePoint Timer Service.

Why Some Users See Access Faster Than Others

Group owners receive access updates faster than regular members in some cases. When a user is added as an owner of a Microsoft 365 group, SharePoint treats the change as a high-priority event and may refresh the cache within 30 minutes. Regular member additions do not receive this priority treatment. This difference can confuse administrators who test group membership changes by adding themselves as owners and then expect the same behavior for all members.

Steps to Force a Group Membership Cache Update

You cannot trigger a full cache refresh from the SharePoint user interface. You must use PowerShell or wait for the automatic refresh. The following steps use SharePoint Online Management Shell to force an update for a specific site collection.

  1. Install and connect to SharePoint Online Management Shell
    Open Windows PowerShell as an administrator. Run the command Install-Module -Name Microsoft.Online.SharePoint.PowerShell if the module is not already installed. Then run Connect-SPOService -Url https://yourtenant-admin.sharepoint.com and sign in with a global admin or SharePoint admin account.
  2. Set the group membership cache expiry for a specific site
    Run the command Set-SPOSite -Identity https://yourtenant.sharepoint.com/sites/yoursite -GroupMembershipCacheExpiryHours 0. Setting the value to 0 forces the cache to expire immediately. After the command runs, SharePoint will query Azure AD for the current group membership on the next request.
  3. Verify the change took effect
    Have the affected user navigate to the SharePoint site. If the cache was cleared, the user should see the site in their SharePoint sites list and be able to access site contents. If access still does not appear, wait 15 minutes and repeat step 2.
  4. Reset the cache expiry to the default value
    Run the command Set-SPOSite -Identity https://yourtenant.sharepoint.com/sites/yoursite -GroupMembershipCacheExpiryHours 24 to restore the default 24-hour cache interval. Leaving the value at 0 causes SharePoint to query Azure AD on every request, which degrades performance.

ADVERTISEMENT

If SharePoint Still Has Issues After the Main Fix

User still cannot access the site after cache refresh

If the cache has been cleared and the user still cannot access the site, the problem may be with the Microsoft 365 group itself. Verify that the user was added to the correct group. Go to the Microsoft 365 admin center, select Groups, then Active groups. Open the group and check the Members tab. If the user is listed, the group membership is correct. If not, add the user again and wait 30 minutes before retesting.

Site permissions show the group but access is denied

SharePoint site permissions may list the Microsoft 365 group as a member, but the user still receives an access denied error. This issue can occur if the site has unique permissions that override the group’s inherited permissions. Go to the site, select Settings, then Site permissions. Click Check permissions and enter the user’s email address. The results will show which permission level the user has and whether it comes from the group or from a direct assignment. If the user has no permissions, add the group to the site’s permission list directly.

Group membership sync is delayed for all sites in the tenant

If no new group members can access any SharePoint site, the tenant-level cache may be stuck. Run the PowerShell command Set-SPOTenant -GroupMembershipCacheExpiryHours 0 to force a tenant-wide cache refresh. After the refresh, reset the value to 24 using the same command with the value 24. This action affects all sites in the tenant and should be used only when multiple sites are affected.

Group Membership Cache Behavior: Default vs Forced Refresh

Item Default Cache (24 hours) Forced Refresh (0 hours)
Cache update frequency Once every 24 hours On every page request
Performance impact Low — cached data is reused High — each request queries Azure AD
When to use Normal operation Testing or troubleshooting a specific user
Revert requirement Not needed Must revert to 24 hours after testing

The default cache behavior is appropriate for most organizations. Forced refresh should be used only to resolve a specific access issue for one user or site. Leaving the cache expiry at 0 causes SharePoint to query Azure AD on every page load, which increases latency and may cause throttling.

You can now identify why group membership changes do not immediately update SharePoint access. The root cause is the 24-hour group membership cache. To fix a specific user’s access, use the Set-SPOSite command with GroupMembershipCacheExpiryHours 0 to force a refresh, then revert to 24 hours. For ongoing management, consider using the SharePoint admin center Check permissions tool to verify access before waiting for the cache to update.

ADVERTISEMENT