As part of Atlas, our Digital Workspace solution, we provide ConneX:
“Atlas ConneX addresses the business challenges around self-service in Office 365. Atlas ConneX efficiently lets a non-technical user create a collaboration space with the right permissions and structure within minutes: but still following rules laid down by the business. Atlas ConneX is a game changer for IT and business users!”
One of the latest features we have shipped in Atlas ConneX, is the ability to provision both Public and Private Microsoft Teams, using custom Teams templates, tailored to the organisation (during our consultancy phase, we work together with our clients to define those required templates that support specific user/task journeys and therefore increases the ease-of-use and productivity). This was an important milestone to drive increased support for “Teams as a Platform”, increase well-governed self-service and maintaining a good and effective information architecture.
Ignoring the complex architecture behind ConneX, one of the main steps when provision Teams, is calling Microsoft Graph API, to, well, provision the Team. We are using the Graph SDK for .NET, which as of today is pretty mature, and makes the process a lot easier, as we do not have to deal with the raw HTTP request / response. The code snippet to provision a Team, looks like this:
Although the Team was provisioned correctly, we realised that the Team (and therefore all the content related to the Team, like files in the SharePoint library) was not surfaced in the Office 365 search (or SharePoint search if you will). So nothing at all was coming up for the Owner of the Team. Why was that?
OK, let´s start confirming what the theory says:
If you create a Private Office 365 Group (or soon to be known as “Microsoft 365 Group”?... see here… yay!), the group and content, will not be returned in SharePoint search, for users that are not *members* of the Group. This makes sense as it is is “private”, although you can still find the group in some OOTB places, such as discovering Groups in Outlook. Side note: If you want to avoid this, set the Group properties hideFromAddressLists and hideFromOutlookClients to True). But to confirm, if I am a member of the group, I should get results from that group in SharePoint search.
OK, this is the theory, however, when Atlas ConneX provisioned a private Team, the content is not appearing in SharePoint search, even for users that are *Owners* of the group. Curiously enough, if the Group is created using the OOTB mechanisms: Teams App, SharePoint site, etc., it does work as expected, and you get search results in SharePoint from those Groups… so, what is the difference between our Groups created from ConneX, and the ones created by OOTB approaches? … join me in this interesting story!
First, I cast my eyes on Graph SDK, as I had noticed on some occasions that the request created by the SDK, was not exactly what I was expecting, and some properties were missed, and so you have to do some extra bits to make it work. So to start with I created the Team, just using Graph API and Postman. This process is very well explained here “Creating teams and managing members using Microsoft Graph”.
At this point, I was reproducing the same issue, and not getting content from that Team in SharePoint search. So that confirm that it was not an issue with the SDK (sorry guys for doubting about you).
My next step was to compare a Team created using the Graph API versus a Team created by Teams App. This also produced a consistent result, and I didn’t see any difference.
Then, I wondered, is this related to a Team? Or just the Group created behind the scenes? So, I repeated the process, but with just a Group… same result (no search results).
Then, considering the issue is at Group level, and with SharePoint, I jumped into the SharePoint site, and was checking permissions in there. Are the Owners in the proper SharePoint group? And the members?
Why can “Carol Danvers” not get search results from this group if she “owns” it?! … OK, let´s go classic troubleshooting style and check permissions for Carol in this site, and let´s compare them with the ones she gets in a Site/Group created by the OOTB tools…
Here is the result for a Group created using the API:
Well, Full Control, makes sense…
Same window for a Group created by OOTB tools:
Hmm… Full Control (expected), but also Edit, given through Members group. Why Members? I mean, user Carol Danvers is actually the Owner of the Group so “Member” should not be necessary.
But this is the only difference, let´s do something, let´s check the Owners and Members list, using Graph API.
Members and Owners list for a Group created using the API
Members and Owners list for a Group created using the OOTB tools:
Why are the Owner users, also being returned as Members? I imagined that this is the reason why I´m getting Carol Danvers “Edit” permissions in the SharePoint check permissions screenshot above.
I know what you are thinking, so the next question was: would I get my Private Group in search results, if I add my user as Member, even if I'm an Owner? (I mean, if my user is added as member and owner when I create the group using Graph API)?
And the answer is YES!... if you would like that your private group appears in SharePoint search for the users that are “owners” of the group, then you must add them also as members too. I suppose that when SharePoint search applies security trimming to the Group, is only checking the Members list of the Group, and ignoring the Owners list. I guess this is why the OOTB tools apply Owners to the list of Members of the group (despite the fact that in the UI, owners are only showed as Owners and not in the Members list).
In my opinion, this is a bug in SharePoint search or Graph, and will do my community duty and ping some Microsoft folks to report this, but in the meantime, here you have the explanation, and the workaround.
Hope you had as much fun reading this article as I had dealing with the issue 😊