Debugging Issues with Content Type Hub Syndication

As we’re moving into the “modern” era in SharePoint Online, we will need to use the Content Type Hub more and more frequently. This is due to the fact that we are moving from a subsite-laden pyramid of sites to a flat topology of sites. Where we used to build our information architecture – Site Columns and Content Types – in the root site of the pyramid and utilize it in all the subsites, we now need to elevate our information architecture to the Content Type Hub if we want to ensure reuse and clean management.

The publishing process from the Content Type Hub is sort of crappy, to be honest. The capabilities there were really cool when they first came out in SharePoint 2010, but it truly needs some love from the SharePoint folks in Redmond. I know it’s on their list, but in the meantime, we need to struggle with it as is.

To help with this, we can turn to some tooling in in each site that I’m not sure a lot of people know about. In every Site Collection – therefore every modern site – there’s a Content type publishing settings page that can help at /_layouts/15/contenttypesyndicationhubs.aspx. This page allows you to “pull” on the next publishing round, and also lets you drill into any issues occurring in the process.

If we look at the Content Type Publishing Log, we can see if there are any conflicts blocking the publishing process.

 

There are a number of reasons why you may not see your Content Type available in a particular Site Collection. Here are two examples.

  • The error in the green box tells us that there is a conflict with the Content Type name CDM Document already being in use.
  • The error in the red box tells us the Site Column Indication is already in use in the current Site Collection.

Either of these situations can occur when you prototype something in a particular site and then build the Content Type in the Content Type Hub for wider usage. As we move to modern sites, I expect this will happen to us more and more often.

In either case, this points out the importance of having a holistic view of your information architecture. The flat nature of modern sites is making all of this far more difficult, as we must use the Content Type Hub to get any common structures in place.

Note: Sharegate is EXCELLENT for copying Site Columns and Content Types from one site to another. It doesn’t eliminate any of these problems, but it makes moving your information architecture around much easier.

So the next time you think the syndication (publishing) process just isn’t working because you don’t see the Content Types where you expect them, don’t blame the timer jobs – be sure to look at the Content Type Publishing Log. You’re likely to be able to track down the issue.

 

Similar Posts

8 Comments

  1. Recently told by someone whose opinion and expertise I respect that Microsoft is moving away from content types. I was about to apply content types to an additional site collection and want to be sure that that effort will be worthwhile. Can you please confirm that content types are here to stay?

    1. @Lynn:

      I’ve had conversations with some of the product team folks in Redmond, and Content Types aren’t going anywhere. The main messaging around this (unfortunately) seems to be coming from outside people trying to read the tea leaves. We’re definitely in an awkward place right now, with site typologies flattening and the Content Type Hub under-powered to support that.

      Let me see if I can get you any “official” word on this.

      M.

  2. Question. How can I migrate my existing custom columns and content types from a current site collection to a content type hub? How do I resolve these syndication conflict failure? Thanks!

  3. Even if I also don’t think content type will go away, there are some new features that make them less valuable and could let us think it will go away:

    the new labels and retention policies that applies to the whole O365 environment
    the library “New” menu configuration where you can attach templates without the need to use content types…
    flow probably replacing sharepoint workflow so attaching to content type will be less frequent

    Still it is helpfull in situation you need to manage different set of attributes in the same library/list but other than this….

  4. Nice article

    Its been a while since you wrote this article. Any further development/thought in Content Type Hub area? Should we use it ?

    We are having issues with this where it takes hours to get content type to be available. Sometime it takes days to be available in our satellite location. Yes days that’s totally unacceptable.

    If the message is still use the content type then this kind of behavior its totally useless. Microsoft should really make things clear on this.

    No offence to anyone but I am frustrated

    1. @Ravi:

      I understand your frustration. There hasn’t been any investment in the Content Type Hub in years. That said, they are investing heavily now. You should check out the Project Cortex sessions from Ignite.

      Rather than using the Content Type Hub these days, though, I’m using Site Scripts and Site Designs. It works much better for targeting your IA to specific sites rather than the all or nothing approach with the CTH.

      M.

  5. Thanks Marc for the response.

    I did look at Project Cortex and couldn’t find what exactly they are doing with CTH. On top of that its planned for release 20201H and 20202H which is almost a year to wait for this.

    Obviously we can’t wait for that long :(

    I do agree that with looking at the current scenario we are in the only option that we left with is to create content type locally.

    Thanks again

Leave a Reply

Your email address will not be published. Required fields are marked *

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