In the new flat world of modern SharePoint, each unit of work gets a separate site collection. Hub sites allow us to eliminate the inflexibility and governance limitations of “dreaded” subsites, while providing a way to replicate one of the key benefits of subsites — a way to create a shared experience among related sites. Hub sites can help kill subsites, but not without a little planning.
Getting started with SharePoint hub sites
I had the opportunity to work with Microsoft to create the hub site planning guide. I encourage you to read the entire planning guide. Meanwhile, here are some additional tips to help you get started.
1. Make sure you understand the types of sites in SharePoint
Alub site is not really a new type of site — it’s basically a capability that you enable for an existing site — either a team site or a communication site. Most hub sites will be communication sites, but there is no technical requirement that forces this to be true. I extended the table in the blog post about team sites and communication sites in the hub site planning guide, but the key to understanding the type of intranet building block sites in SharePoint is to think about the business objective of the site:
- Team site: Collaborate with members of a project or organizational team
- Communication site: Communicate to a broad group of people or the entire organization
- Hub site: Connect related sites to create a shared navigational and content experience
2. Don’t plan on making just one hub site for your entire intranet
It is tempting to think of a single hub site as a way to provide global navigation for your intranet, but try not to think this way. I guess technically you could make just one hub site for your entire organization, but I don’t recommend it, not even for very small organizations. Here are two important reasons this doesn’t make sense:
- Context. One of the biggest benefits of hub sites is that they allow you to collect contextually related information. For example, you could make a hub site for sales and then have all the sites for each region be associated to the sales hub. One of the benefits you would now get is the ability to see sales-related news from across the country on the sales hub. This allows sales team members in different regions to easily discover news and other information that is contextually related to sales in a single place — all about sales. If there were only one hub for the organization, sales news would be co-mingled with HR news – which reduces the impact for news authors and makes news less contextually relevant for the sales team.
- Search. Another important benefit of hub sites is that they provide an easy way to scope search to the sites that are associated to the hub. By restricting the scope of a search query to hub family, you get the benefit of a much more relevant and limited pool of search results — ultimately helping searchers find what they need quickly so that they can apply the information they gather from searching in their work. If you have just one hub site, you are not getting any benefit of the search scope provided by the hub association.
3. Think about naming conventions
Before you even create your first site in Office 365, it’s a good idea to do a little planning about site names. When you create a site in Office 365, a team site or a communication site, you effectively make a land grab for the URL name — and the first site created wins. Without naming conventions, you can end up with some confusion about who gets to use which site URL name.
For example, if the IT team creates a private team site called IT, the URL /sites/IT will not be available for the communication site that IT wants to use to showcase their services to the rest of the organization. That site could be /sites/InformationTechnology — but it can’t be IT. And if IT wants to create an internally facing communication site for just the people who work in IT, there will need to be yet another name. If you try to create a second site called IT in SharePoint, it will get created, but the URL will be /sites/IT2.
Now that hub sites are added to the mix, it is even more important to think about site naming conventions — and to communicate them to everyone who can create a site (which may mean everyone in the organization). Here are some naming conventions that I’ve been using as a starting point with many of my clients:
|Communication Site||Name of business function||HR
|Internally-facing Communication Site||Inside [Name of Function]||Inside IT
|Team Site||Team name or name that clearly indicates membership||IT Team
[Name of Project] Team
|Hub Site||Name of function, geography-function, or portfolio||HR Hub (or HR)
U.S. Sales Hub
4. Determine your ‘hubification’ strategy
There are really three major ways to think about your hubs:
- Organization or functional (for example, HR or sales).
- Geographic (for example, a function in a geography like U.S. sales or a country, such as Austria, where all the associated sites are the function/organizational units that “belong” to Austria). Note: If you set up SharePoint Multi-Geo for your organization, only sites within the same geographical location can be associated with a hub site.
- Portfolio (for example, a group of related projects such as all of the project and/or communication sites associated with a major acquisition or integration).
These are not mutually exclusive. In fact, you will likely have hubs that create families for all three purposes. But it’s a good idea to take a step back and think about what makes sense for your organization before you start randomly hub-ifying.
As of right now (June 2018), you can have only 50 hub sites in your tenant. But this is not a firm and fast limitation, and Microsoft has indicated that the number will be increasing. However, you may not need a hub site for every function or every geography or every portfolio — so think about your hubificaiton strategy before you worry too much about the number.
5. Plan — and test — navigation
As the owner of a hub site, you have a choice about what appears in the shared hub navigation. This is something you really want to think about because you have options about how you roll up content and showcase sites and content in the hub navigation. User experiences should drive all navigation decisions, and it’s a good practice to test your navigation with users to make sure you get the outcomes you want. Your hub navigation can include all the sites that are associated to the hub or not. It can also include sites that are not associated with the hub. Here’s an example where this might make sense.
Say you decide to make a finance hub with all the communication sites that “belong” to global finance. However, your organization also has finance teams (and sites) for the finance departments in each of the countries in which you operate. Your hub strategy has a combination of organizational hubs (finance) and geographic hubs (France), and you decide that the Finance-France site is going to be associated with the France hub, not the global finance hub. In this scenario, it could be helpful to list all the geographically based finance sites in the navigation for the global finance hub in a “category” called Country Finance Sites. This creates a comprehensive navigational experience from the global finance hub, but when the user clicks to navigate to any of the local finance sites, they will move to the geographic hub — and the look and feel and even language for the site may change because they are now in a different hub.
This scenario is a great example of the power and benefit of hub sites. Let’s say that at some point in the future, you change your mind about your hub strategy and you want all finance-related sites to be associated to the finance hub. No problem! Just change the association for the Finance-France site. And if the Finance-France site is already linked in the navigation on the France hub, you don’t even have to change the navigation. The Finance-France site is now associated to global finance, but the URL hasn’t changed and none of the local references needs to be updated. There will be some additional implications when the ability to share content types in a hub is available (a feature I’m hoping for), but this example demonstrates why hub sites beat sub-sites for the inevitable changes in every organization.
6. Don’t hubify where you don’t need to hubify
Another principle to think about: You don’t need a hub for one site. Don’t make a hub for a global function just because every other function has a hub site. Hub sites are designed to create families of related sites. If there is no family, you don’t need a hub.
That doesn’t mean you won’t want to find a way to show how your hubs and other sites come together to create your intranet or digital workplace. I think that’s where global navigation comes in, but until we get that capability in Office 365, you can represent the overall navigational strategy for your intranet on your “home home” site (your organizational portal).
Go forth and hub!
There are more tips and advice about hub site planning in the Hub Site Planning Guide, so I recommend giving it a thorough read. Here are some other key resources for your hub site journey:
- Microsoft blog post: Organize your intranet with SharePoint hub sites
- What is a SharePoint hub site?
- Create a hub site in SharePoint Online (Remember, you must be a global or SharePoint admin in Office 365 to convert an existing site to a hub site using Microsoft PowerShell.)
- Set up your SharePoint hub site
- Associate a SharePoint site with a hub site
- Disassociate a SharePoint site from a hub site
- Change the look of your SharePoint site
- Customize the navigation on your SharePoint site
- SharePoint hub sites feature overview