Article Updated: June 26, 2019

Spoiler alert…

They don’t!

Introduction

Hub sites are a newer concept in SharePoint that use a central site to tie together SharePoint sites into a hub and spoke model. They provide common branding and navigation, assist with aggregation and rollup, and help to scope search.

When I introduce the concept of the hub and spoke site model to a client, I generally get a standard question:

“If this is the replacement for subsites, then how do the hub site permissions work on the spoke sites?”

As I have stated above, the answer is simple, “They don’t.”

I was not in the room when the engineers at Microsoft developed the hub and spoke model, but I can guess that the conversation went something like, “SharePoint permissions are confusing, how can we address that? Maybe we just simplify them by removing the complexity?”.

From my experience with SharePoint permissions, I can say this:

Regular people do not understand SharePoint permissions.

Even some seasoned SharePoint professionals don’t fully understand SharePoint permissions.  

Mike Hatheway

So How Should We Manage Permissions in Hub and Spoke?

There is no silver bullet here. I’ll pull out the ol’ “It depends” line that consultants love to throw around. That said, there is a pattern I have been following that seems to help. This pattern seems to work best when the hub based is around units or functions.

I have been promoting hub models that contain at least one Team site. I call this team site the “Main Team Site”. It is created as the main place for the team (unit or function) to collaborate. It also comes with a handy O365 security group.

Along with this, I also promote attaching other Team sites (e.g. subsets of the main team), non-group connected Team Sites, Communication sites, and even classic sites (just give them a modern homepage).

The result is something like this:

From this example, we end up with two O365 groups:

• HR Team
• HR Managers

And we have four other sites that have default SharePoint group permissions.

The bonus is that we can use these O365 groups to define permissions on the hub (and other sites).

So maybe the HR Managers will be the owners of the entire Hub. If that’s the case, we can use the O365 group created on the managers team site in the Owners group for the hub site. And maybe the entire HR Team needs to be able to post news articles and create pages on the hub. Then we can just add the HR Team O365 group to the members group on the hub site.  

In the end, we might end up with something like this:

• HR Hub Owners
  • HR Managers Members (O365 Group)
• HR Hub Members
  • HR Team Members (O365 Group)
• HR Hub Visitors
  • Everyone except external users (built in-group)

We can reuse these groups on any site. Even Team sites. We can easily add the O365 groups to the SharePoint groups on Team sites. Maybe we want the HR Manages site to be a place where the HR Managers create content, but the rest of the HR Team should be able to view that content. We simply add the HR Team O365 group to the Visitors group on the HR Managers team site.

One Issue

When you define an O365 Group, you can assign Owners and Members (and Guests) to that group. However, we can’t use these “sub-permission groupings” from the O365 Groups elsewhere in SharePoint. E.g. We can’t say that we want the owners of the HR Hub to be the owners of the HR Managers O365 group.  

Conclusion

The hub and spoke model really isn’t about permissions at all, but with some planning, you can get some re-use out of the groups you put in place.