Who can associate a site with a SharePoint Hub?

I’m sure many of you will have started making use of hub sites. If you haven’t, why not? Hub sites provide a clean and intuitive way of structuring content in SharePoint Online, which are ready to use out of the box.

For me, perhaps the best part of the hub model is the feedback I’m getting from users. I’ve already spoken to various organisations who are both aware of hubs and excited to use them – something that just underlines how hub sites are a superb addition to SharePoint Online. For me, this is mostly because hub sites provide something that many organisations have been hoping for – a native and recommended way to structure your workspaces, without needing 3rd party toolsets.

I’m keeping my fingers-crossed that hub sites might finally kill-off the strange fascination that many seem to have in constructing antiquated and inflexible hierarchies of SharePoint sites – please let those days be behind us!

The organisation I’m currently working with are a multinational conglomerate (with more than 100k staff), comprising multiple large and quite distinct businesses. The organisation has decided to use a single shared tenancy for all of their businesses and with Intelogy’s assistance have opted to use the hub model as the backbone of their SharePoint governance. As you might imagine, establishing precise options for hub permissions and governance (as of early-February 2019) has been essential. Hub association permissions

Currently, the following permissions need to be established to allow a user to be able to manage the association of a site collection with a hub. For the sake of brevity, I’m referring to the site collection that the user is attempting to associate with the hub as the ‘child’.

1) Site Collection Administrator – A user needs to be a Site Collection Administrator within the ‘child’ site collection that is being associated with a hub. Merely having ‘Full Control’ over the ‘child’ isn’t sufficient. For example, via the UI, only Site Collection Administrators get to see the ‘Hub site association’ field on the Site Information panel:

2) Hub site permissions

Having permissions in the ‘child’ site collection alone is, by itself not sufficient to manage the association. The user also needs to have a base level of permissions within the Hub itself; thankfully being a member of the Hub’s ‘Visitors’ group is sufficient.

When a Site Collection Administrator within a ‘child’ site collection attempts to associate it with a hub that they have no permissions within whatsoever, they will be shown the following error message:

It’s worth noting that the Site Collection Administrator of a ‘child’ can, however, disassociate their site from a hub (by selecting ‘None’), even if they don’t have any permissions within the hub itself.

3) “People who can associate sites with this hub site”

Finally, there is a third separate role that is used to determine who can associate a site with a specific hub. In the modern SharePoint Admin Center, when you register a site as a hub, you will notice the relatively new ‘People who can associate sites with this hub site’ setting. This setting is something that we’ve been able to configure via PowerShell for a while now (see Grant-SPOHubSiteRights & Revoke-SPOHubSiteRights).

When a hub has been configured without any ‘People who can associate sites with this hub site’, then all users (who meet the other permission requirements detailed in 1 & 2 above) can associate their site collections with this hub.

However, when a hub has anyone set as being one of the ‘People who can associate sites with this hub’, then as you might imagine everyone else within the organisation is not able to make associations to this hub.

Currently, the UI only supports addition of ‘People who can associate sites with this hub site’ when the hub is initially registered, so PowerShell needs to be used to make any subsequent updates to membership.

Thinking about real-world usage, I immediately tested setting Security Groups within the ‘People who can associate sites with this hub’ setting. The summary of my findings is that while Security Groups seem to be added without issue, their members don’t get given the rights to make associations with the hub. However, repeating the same test with Mail-Enabled Security Groups seemed to work perfectly (I just wish that I could do the same in Office 365 Groups!).

To make everything a little simpler to digest, I’ve consolidated the above into the following graphic, which I hope will provide the community with a simple reference whenever anyone is defining permissions for hub site associations: