Content Type Hub. What’s vNext?

Reading Time: 5 minutes

If you want to standardize Information Architecture (IA) across your SharePoint Online environment at scale, you’ll likely want to leverage some automation to do it. I recently posted a Twitter Poll asking how others were doing this today. Even though there were only 61 votes, the conversation that ensued made me realize I wasn’t the only one wondering which option is the “right” one.

IMG_3943

Currently, there are 4 ways to automate an IA push: (with rumors of a future fifth)

  1. Content Type Hub
  2. SharePoint CSOM APIs
  3. PnP Provisioning
  4. Site Scripts and Site Designs
  5. SharePoint Hub IA? (tentative)

Choices

Have I missed an option? If I have please let me know!!!


Content Type Hub

This feature is supported by Microsoft. (Content Type Hub)

This feature has been around for a long time and uses a site collection identified as a Content Type Hub to store and manage the IA components (site columns and content types) you’d like to publish to all subscribing site collections thru a syndication process. I’ve used this feature in the past in SharePoint on-premises environments and have had a fair amount of success with it. However, people I trust in the community have had a different experience when using it, particularly in SharePoint Online environments, causing me to pause and re-evaluate whether I should continue to use this for new solutions I’m provisioning.

Issues I’ve heard from the community are:

  • You don’t control the timing of the syndication process like you can in SharePoint on-prem which causes issues at times
  • In environments with a large number of content types, it does not scale well
  • Removing artifacts from subscribing site collections is problematic and won’t always remove things you want removed

Check out these resources:

If you have other issues, let me know and I’ll include it in this list and ensure it’s added to UserVoice.


SharePoint CSOM APIs

This feature is supported by Microsoft. (Create SharePoint Content Types by using CSOM)

You can use the SharePoint CSOM APIs to programmatically create content types and site columns and link them together. This option is highly customizable since you’re in control of the code however it will require a skilled developer. Depending on the specific requirements you have and the skill level in your organization, this may or may not be a suitable option for you.


PnP Provisioning

This feature is supported by Microsoft and the open-source community. (PnP PowerShell overview)

The PnP (Patterns and Practises) provisioning technique has been around for awhile and is an excellent way to deploy IA components across numerous site collections. It can be used for very complex IA scenarios and updates. Check out this recent post by Tom Castiglia called Tips and Tricks for automated SharePoint site provisioning with PnP for some excellent guidance on how to start using them. For this option, you should have someone with a strong IA technical background who understands SharePoint IA and the effect changes have.


Site Scripts and Site Designs

This feature is supported by Microsoft. (SharePoint site design and site script overview)

This is the relative newcomer to the block. It is comprised of JSON file(s) to define the IA components. A Site script is created from a JSON file and any number of these can be combined to form a Site Design. You can then apply this Site Design to both new and existing sites. I really like this option since you can control the JSON files and organize them for re-use across multiple site scripts. This option is early-on in its development and doesn’t have all the capabilities that PnP has (localization, maximum 30 actions allowed) so depending on your requirements, this may not be a good/sufficient option for you.

If you are going to use this technique, check out the GUI tool www.sitedesigner.io by Mikko Punamaki to automatically generate a JSON file for you.

Like the PnP PowerShell option, this option requires a strong technical foundation for IA and then building and deploying the scripts.


SharePoint Hub IA… or whatever vNext is

In several sessions at the recent Microsoft Ignite conference in Orlando, I heard reference to standardizing IA within a SharePoint Hub. Although I don’t know how this will be implemented, this may prove to be a promising option. Imagine defining your IA once in a SharePoint Hub and any site joined to it would automatically inherit the Hub’s IA! This is similar to the concept of the Content Type Hub syndication process, but done at a more targeted site collection level. I’m eager to learn more about how this is implemented in the coming months, but until that happens, this is not an available option.


Which one should you choose?

Having options is nice and all, but if you’re faced with building a solution today (as I recently was), which option should you choose? To be clear, all options require a strong understanding of IA concepts for pushing out changes, so you don’t get yourself (and your environment) into trouble.

I believe it primarily comes down to these 5 factors:

  1. How complex is the Information Architecture? If it’s relatively simple, likely any of the options would work, including the Content Type Hub. However, see points 3 and 5 below. 😊
  2. How often do you anticipate changes will occur? Trust me… prepare for future changes to the IA and you won’t get into trouble. Provisioning a net new IA is the easy, “happy-path” part – it’s the ongoing changes where the complexity happens. I believe Site Scripts/Site Designs is a great option to handle ongoing changes however I haven’t tested all types of changes that can happen in real-world. If Site Designs can’t do what you want it to and/or your requirements are more complex, PnP scripting may be a better way to go.
  3. How big is your environment? Do you have 5, 10, 100, 1000 or 10000 site collections you’re wanting to sync the IA changes across? Do you have millions of items/documents using the Information Architecture components? If you do, then whatever solution you come up with will need to scale across potentially many site collections. With the limitations of the Content Type Hub above and the fact that pushing updates across a large environment could potentially take weeks using that technique, I would not choose it in large environments. For the other options, you would be able to script out, and therefore control the process.
  4. Do you have someone in your organization with a strong IA technical skill set? If the answer is no, then you should get one. Implementing IA in your environment and publishing it across your organization will require an advanced understanding of SharePoint and Information Architecture. This is not a place to skimp on skill.
  5. What’s your organization’s stance on legacy versus new? Some organizations will want to move away from the Content Type Hub option simply because no new investments from Microsoft will be made in this feature and therefore building a new solution reliant on it is a bad idea. It’s not the future. This, in conjunction with the issues I identified earlier in this post, are valid reasons for not choosing it as an option. The fact that new investments are being made in both Site Design and PnP templates provides some level of insurance that your provisioning solution will stand the test of time moving forward.

My Current Stance

Today, I’m going to start with Site Scripts and Site Designs to replace the functionality currently being provided by the Content Type Hub feature. Since Site Scripts and Site Designs are relatively new and may not have all functionality I’ll require for a given provisioning scenario, I may have to revert to the more full-featured and robust PnP provisioning engine.

My stance on this may change over time as new capabilities are introduced, but I believe for now it’s a sound approach considering Microsoft is making current investments in this new technique. It works, its flexible, it can be controlled, and I believe it’ll only get better over time.

What’s your stance? I’d love to know.

Thanks for reading.

-JCK

5 comments

  1. Good post! I used to be – and to some degree still is – a big fan of the content type hub, even in online scenarios. Especially if the content types are very similar across all the site collections. I don’t like the hub if you need to publish the CTs to subsets of sites where you often end up having CTs on sites that don’t really need them. Having a decentralized CT Hub to the hub site may solve that, I hope

  2. Looking forward to hearing more about this SharePoint Hub. I’m currently using a Content Type Hub with SharePoint Online, with mixed results. Timing is an issue, with it taking sometimes up to a day for the publishing to complete. I even had to raise a call once when it failed totally after access to the Managed Metadata Service was failing.

  3. Hi Joanne,

    Great article. I have a 30 year background in technology and was fortunate to have a significant background in library science. Having started with SharePoint back in 2001 (Team Services) I immediately saw this was going to be a hot product and the need for IA. Unfortunately the ability to truly create a full featured data taxonomy couldn’t really be done until 2010.

    As a SharePoint MVP, back when I spoke at conferences, IA was my primary topics; and it resonated with most attendees. I’ve been so busy as an O365/SharePoint consultant, I don’t write much anymore and I think its time to start again.

    When I describe a SharePoint data taxonomy, it includes site collections, sites, lists, libraries, content types and metadata. I include the grouping principals site collections, sites, lists and libraries because its a natural means of scoping groups of content. This can be a difficult concept for many as most consider content ownership and forget about the consumer. This is where comprehensive IA principals really shine! It allows us to produce highly relevant search results, aggregate content in a consistent manner, better support single source of truth and so much more.

    I’m really happy to see you discuss this topic because I believe it’s in the top 2 or 3 most important aspects of any SharePoint implementation.

    Over the years, I have learned implementing a data taxonomy in SharePoint has changed. In the 2010 and even some parts of 2013, it was difficult to produce highly relevant search (or aggregate) results without the heavy use of content types and metadata for scoping. Today, I have changed some of my implementation thoughts and am producing a smaller subset of content types; more major categories and fewer sub-categories, etc. We are able to do this because the search services are so much better now.

    Please keep these going and if you’d like to hear more from me, I’d be happy to help!

    Bob Mixon

  4. Joanne, thanks for taking the time to think (and write!) about issues that challenge any of us who care about (and advise clients about) IA. I was curious: did you evaluate Powell 365 as a way to more easily manage site designs (inclusive of metadata, content types, etc.)? I am not well-enough versed in Powell 365’s capabilities to know whether content types are among the site components that can be automated, but it appears to provide a UI for management of a broad array of SharePoint componentry, so I thought it may be an option…

    1. Hi Mike, Thanks for the feedback. No, I haven’t evaluated that product although it’s on my list. I assume content types would be one of the things they’d include, but it would be good to check. Tbh, I’m trying to stay out-of-the-box as much as possible these days as many of my clients are too. I do see the benefit of having a product to hide some of the plumbing though.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.