Content Types

General Notes

While possible to provision content types to subsites in a sitecollection, the recommendation is to provision content types only to the rootweb of a sitecollection.

Consider using the content type hub instead to distribute the content type to various sites, but be aware that with a large number of content types the performance of the content type hub will degrade and performance might be unacceptable for large enterprise scenarios.

An alternative to the content type hub can be to use powershell scripting to provision content types to site collections instead. This will allow for greater flexibility and provides the functionality to update/modify content types in place, which is not possible when provisioning content types using the Feature framework.

We recommend to keep the inheritance hierarchy shallow. This will allow for easier code based maintenance and can prevent unintended side effects to content types deeper in the hierarchy.

Readiness

Analyze your solutions and gather information of the content types being used. Either provision the content types together with the artifact where they are being used, or consider to group the content types in one central provisioning solution. The latter replicates the model of the Content Type hub as such, but gives greater control over when and where a content type is provisioned, without the need to navigate to the site to perform changes.

Do not create too deep hierarchies of content type inheritance, as this will only work adversly in feature maintanance scenarios. If possible, break chains of long content type inheritance into to flatter hierarchies.

Code Examples

The code examples cover the majority of properties of your declarative content types. Notice however that when provisioning content types through REST, API limitations prevents you from adding field references to a content type unless very specific requirements are met. See https://msdn.microsoft.com/EN-US/library/office/jj245869.aspx#postsyntax for more information.