It has been more than three years since Hub functionality made its debut in SharePoint Online. One of my first posts on the topic provides detailed instructions on doing just that. However, ever since we got Hub Sites, there have been many requests from SharePoint administrators (especially those who are part of the large organizations) to associate a hub to another hub. Luckily, we can now do so. In this article, I would like to describe how this feature works and explain some of its nuances and limitations.
What is a Hub?
Before I explain how to nest hubs, perhaps it makes sense first to understand what a Hub Site is. I provided a clear description of it here.
Limitations of a Hub
The most significant limitation of a Hub I can think of is the fact that a site can only be part of one hub at a time. Kind of related to that is that sometimes you want to nest a hub within another Hub. This might not be necessary if you are a small business, but if you are a large organization, you might want to nest, say, a Human Resources Hub inside of the Corporate Hub.
How to associate a Hub to another Hub
The new feature that was recently rolled out in SharePoint tenants is resolving the above limitation. Here is how to achieve this.
- Navigate to the SharePoint Admin Center by clicking Microsoft 365 App Launcher > Admin
- Under Admin centers, click SharePoint
- Click on Active Sites
- Click the checkbox next to the Hub you want to associate with another Hub, then Edit Hub site settings under Hub dropdown
- On the next screen, choose the Parent Hub you want to associate to, then click Save
- That’s it. In case you are trying to associate a hub to another hub, and that hub you are trying to associate has child hubs associated with it, it will display them to you on that screen above as well.
What happens when you add a hub to another Hub
Now, I should have probably started this article with this section so that you would know what happens when you nest hubs, but I did not want to disappoint you right away 😊. The only thing that happens is that the nested hub becomes part of the parent hub search scope. That means that I can search both the parent hub and a child hub using the search box on the parent hub.
Automatic links with global navigation
There is nothing that happens to the navigation (more on this below). However, you are getting two additional choices within the Hub Navigation.
When you choose Associated Hubs, it states that it will “Add links to hub sites associated to the same parent hub.” In pure English, it will add links to all the child hubs UNDER the Hub where you are adding Associated Hubs navigation link.
Associated Child Hubs
When you choose Associated Child Hubs, it states that it will “Add links to child hub sites associated to the same parent hub if available.” In pure English, it means that it will add links to the other hub sites connected to the same parent hub, as well as the link to a parent hub site itself.
If you find the above terminology confusing, trust me, you are not the only one. The labels (Associated Hubs and Associated Child Hub Sites) could be more descriptive. The picture is worth a thousand words, so I assume the below diagram will help.
Limitations of a nested Hub Model
This brings me to the section I wish I did not have to write… Unfortunately, nested hubs fall short of expectations I think many had when the nested hub feature was announced. These are the few significant limitations I see. Below are a few I came up with, and I guess this is more of a personal opinion rather than a generic set of limits.
- Deep hierarchies. I can see a need to nest hubs, but with nested structures comes the complexity of maintaining them. It is almost like back to Site Collection/Subsite model. In my opinion, two levels (keep it relatively flat) would have been a better option.
- No navigation inheritance. While you can build additional links in the navigation using the options described above, the navigation from the parent hub does not render on the child Hubs. That means you cannot build consistent navigation among Hubs for the whole tenant. You need to manage navigation on each hub manually if you desire such consistency.
- No branding inheritance. Same as with navigation, there nesting a hub within another hub does not alter the branding (theme) of a Hub. So that means that you would need to maintain themes/branding on each hub separately. On one hand, this is OK, but on another, I can see a need/desire for Marketing folks to have consistent themes/headers on all sites throughout the whole tenant.
- New Hubs are not reflected in the Automatic Links for Hub Navigation. When you set up Associated Hubs and Associated Child Hubs navigation described above and then decide to create a New Hub and nest it within another Hub, the Associated Hubs and Associated Child Hubs navigation stays as-is. So that means that you would need to manually add links to the newly added Hub to every Hub that is nested if you desire consistent navigation across all hubs sites.
- Search only impacts the first three levels. This could be confusing. It does not prevent you from building more than three levels of Hubs; however, it warns you in the Admin Center that only the first three levels will be searched. This is not apparent to the end-users, though.
- Impossible to understand the Search Scope until after the search is performed. If you are the end-user and want to search the hub, it is not clear what sites will be searched until after the search is performed. At that point, it will display the search results as well as the breadcrumb of the location searched.
Hard for users to understand the search scope before performing the search from any given Hub
However, once the search is executed, it does show a breadcrumb of Hubs (search scope)