Adding Group Members Using Microsoft Graph May Result in Long Delay Before Membership is Effective

Published by Mika Berglund on

In a project I’m currently working on at work, we are modifying group members in Azure AD from an Azure Functions application. That application uses application permissions to authenticate to Microsoft Graph. To give the application permission to manage group members, we granted the following permissions to the application.

  • Directory.ReadWrite.All
  • Group.ReadWrite.All
  • User.ReadWrite.All

With these permissions the application was able to add members to and remove members from an Azure AD group. The same code applies to both security groups and Office 365 groups. Since team sites in SharePoint Online and teams in Microsoft Teams are also based on Office 365 Groups, the application was automatically capable of managing members to team sites and teams too.

However, we pretty soon noticed that there was a delay before the added member was visible in any UI. There was also a delay before the membership was actually effective. This delay could vary from a couple of minutes to several hours. Sometimes the change was not visible or effective until the next day.

We noticed this both on the Azure AD management portal, and when viewing the members on both SharePoint team sites as well as in teams in Microsoft Teams.

How we Solved it

To make a long story short, the solution was pretty simple. After all, it was just a matter of permissions. We added the following application permissions to our application.

  • GroupMember.ReadWrite.All
  • TeamMember.ReadWrite.All

And bang! The changes started to show up in just seconds. Even in Microsoft Teams, the membership change was visible virtually immediately. That change also reflected immediately to the guest user logged on to Microsoft Teams. When the guest user was in Teams, and the application removed their membership from a team, it automatically disappeared from the Teams client. Even without any actions by the user. Previously, Teams was the application with the longest delay on average, but now, that delay was all gone!

I hope this can help you and save you the countless hours I tried to figure this out. Somehow, I just could not understand that we needed to add more permissions, since our application was capable of modifying group members. I ran out of options, and as a final attempt I tried to grant almost all permissions to our application.


3 Comments

Christian Walling · July 17, 2020 at 18:23

Hi Mika,
did you get that to work consistently?
We are running into the same problem and tried your solution (and others we found – like using the Graph beta endpoint), but adding the permissions to the app didn’t change anything for us. It seems to be a matter of luck. Sometimes it works, but most of the time the user added to the team is not yet ready to be used and not shown in the Teams client.

    Mika Berglund · July 18, 2020 at 17:04

    Hi Christian!

    I would say that I got it to work consistently, yes. I was able to reproduce the problem first without adding the additional permissions. Then I added the permissions, and the memberships I modified through MS Graph started to take effect almost immediately. Also in Teams, which previously probably was the most problematic application.

    I also tried to remove the permissions, and noticed that the delay returned again.

    Sometimes, occasionally, there is a very long delay even with the added permissions. I suspect that it might be connected to a newly created account, either guest account or member account, but it’s pretty hard to verify, since a new account is only new for a relatively short time.

    Mika Berglund · July 20, 2020 at 12:15

    You might also want to check out this article from my colleague about the new Teams API in Microsoft Graph.

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *