October 8, 2020 // By Ralph Rivas
(Author’s note: This article is intended for M365 or SharePoint online administrators, Developers, Architects, or those in a related role. This article assumes administrative access to a SharePoint Online tenant with the specific abilities to create sites and hubs as well as update their settings in addition to basic knowledge on how to make those changes as needed.)
A very important feature in SharePoint Online over and above the current on premises offerings is the concept of the “Hub Site” which seeks to make connecting and organizing sites based on projects, departments, divisions, regions, etc. easier and more intuitive with discovery, common navigation, branding and search work without much effort beyond the implementation.
When it was first introduced, the biggest question as to it’s implementation viability was the case of permissions which was out of box in older SharePoint site architectures to which its exclusion was not-so-convincingly justified as preventing accidental access. The extra management for this aspect is one of the deterrents to Hub site implementation and it seems that Microsoft is listening to the community by slowly working through solutions that improve on this major point.
Although the Roadmap shows movement towards a complete solution, there are already changes in place which create a nuance that some people may think solves the issue now. Looking at the late update to the documentation on Associating a SharePoint Site to a Hub, it appears to leave an important caveat to the concept of “Sync permissions with the hub” such that the impression may be that we can duplicate Hub Site permissions to sites that are synced automatically. But that is not the case. Sync to Hub is not exactly what one might have expected. The concept is to give "access" not power, so it starts with the hub allowing for this function:
But note the bottom of the statement and the box below it. The statement says that existing permissions on the site will not change. So, what is changing? The only thing that is changed is the group of Hub Visitors you add which allows folks at the hub site who are not part of those team site permission groups to come to the site in READ ONLY mode. Add a user and it says read with a caret but no way to change the caret into anything else beyond "remove".
In the Hub site, a new SharePoint group is added called Hub Visitors:
Now at the hub member target site we would enable the Sync (image captured before the click):
Click on it now and it will add the Hub visitor group to that site and nothing else:
The Owners or Members of the Hub site are not “invited” or brought in, only the Hub Visitors and with only Read permissions!
Again, this is great for "visibility" but not if you are attempting any type of "inheritance" for permissions set in one place.
As in the example above, I added a reader account to the hub which, in a short while, updated the team site’s group. Adding it to the team site did NOT flow back up and I did not test it against a large number of sites though I suspect the update speed will not be any different than the update for the synchronized Navigation or Theme.
Summary
This nuance is permissions would not be the way to auto-permit Master accounts or especially Service Accounts which are typical needs for this ability. Those accounts would likely need more power than read. In short, “Sync permissions to hub” is not an actual sync of permissions but a way to propagate a “reader” group.
But with that, there is perhaps an opportunity as it gives us a model where we could create our own group that, by virtue of the "sync to hub" selection, could do something similar (via code of course) for a Service Account "Group". If and until Microsoft takes care of this, you may want to consider bringing in some knowledge resources to help.