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: