Content type hub is a new feature in SharePoint 2010 to manage content types centrally and publish them to the subscribed sites. As any other new feature introduced in SharePoint 2010, content type hub also has its known limitations and some workarounds for those limitations. If you are eager to know more about content type hubs, please visit my post on SharePoint 2010: Content Type Hubs - Publish and Subscribe to content types
Below are some of the limitations/FAQ about content type hubs:
1. Which field types are supported? Custom fields and external data columns are not supported(you cannot create external data columns in the content type gallery). 2. What happens if a web application is member of two different Content Type Hubs? The default Managed Metadata Service(MMS) gets the priority and will be your content type hub. However, if you customize the service application associations for the web application, you can select the appropriate MMS application proxy for the content type hub.
3. What happens if a user changing a synchronized Content Type inside the Target Site Collection? The subscribed content types are marked 'read only' in the target site collection. Users are unable to manage/change the synchronized content types inside the target site collection. Changes to the content type should always be made in the content type hub and republihsed to push the changes to the subscribed sites.
4. What happens with content types within the sub-site structure? Content type subscription is a site collection level feature, so you consume the content types in the top root web and it flows down the sub-sites.
5. Are Workflows supported and if yes what are the limitations? Unfortunately workflows are not supported. However, once you have your content type published to the target site collection, you can create and associate workflows to the subscribed content types in the target site. But doing so, I have encountered issues such as the workflow association being removed once the content type is republished. A simple workaround is to create list workflows in the target site collection and not associate with the content types.
Update: Read the following blog post on associating workflows with published content types. As always, you are able to still create list workflows in the target site collection instead of associating with the content type if required. 6. What happens with document templates? Document templates associated with the content type are also published along with the subscribed content type. 7. What happens with Document Set content Types? Yes, you can subscribe to document set content types. In this case, all the dependent content types with the document set & the document set itself will be published to the target site. However, you should have the Document set feature activated in the target site.
8. What about feature dependencies? Feature dependencies are not activated automatically in the target site collection. Thus, they need to be activated manually before the subscription process, else the content type publishing job will fail in the target site collection for that subscribed content type. Best example is when you subscribe to document set content types. See 7.
9. Why cannot I publilsh my content type created in a (deployed) solution package (.wsp)? Content types created via object model should use the new SPContentType constructor to create content types which allows you to specify the SPContentTypeId for the new content type. Visit Nick's blog post for more info on this. You can also script the creation of content types using PowerShell, which is another option.
Apologies for the confusion. You are able to publish content types deployed from a solution package (.wsp) - whether you use CAML or server object model or client object model. You can also download a sample VS2010 solution to try the same - http://db.tt/syK0C1a
Please do leave a comment if you want to add more to the list. I am sure I haven't covered everything, so will update this post regularly.
More blog posts on Content Type Hubs:
Web Templates and Cotent Type Publishing
Content Type Hub - Publishing and Subscribing to Content Types Programatically (C# Code)
Workflows and Content Type Hub – Whats the story?
Hi Chak - great info on the hub, but I'm running into a question that I haven't been able to find an answer for. I was wondering if there's any way to have a particular site collection in a web app NOT subscribe to the published content types without moving it to another web app? Is there a site feature other than 'Document ID' that can be deactivated so that the site collection won't pull the published content types?
could you answer a question about Content Type Hubs? If I have a Content Type Hub set up, can I provision a new Site Collection that consumes the Content Types set up in the Hub automatically? I mean by this that perhaps I have a custom feature that creates a list usnig Content Types that will be defined in the Hub? Any help would be great.
i have one question,i have created a feature for couple of custom content types and deployed through wsp package. I am able to publish my content types sucessfully to my subscriber site collections with out any issues. But FAQ 9 stating that it cannot be possible to publish content types created in solution package which i dont agree.
Thanks for the info.
Hi Srinivas, or Anyone,
Could you please confirm how you did this? did u deployed .wsp in subscriber sitecollection and activated the feature there too? to get synced between your hub and subscriber? or u just deployed and activated in hub alone and not in subscriber? Can u publish a content type installed before this hub setup, after I do setup the hub now?
Apologies for confusing everyone that content type created in a solution packages cannot be published.
After reading the comments here and also trying out myself with various programming options - CAML, server object model, client object model - I can confirm it works great and I am able to publish the deployed content types.
Again, sorry for the confusion.
@TM - the only possible way for a particular site collection in a web app NOT subscribe to the published content types is only if you change the associated managed metadata service proxy for the web app.
The decision of using content type hubs should be driven from your requirements and be documented properly in your architecture document to avoid any confusions and situations like what you just mentioned.
@Steve - Content types are by default not published. They should be chosen explicitly to be published. You need to build your custom solution to achieve this.