Managing Document Templates with Content Types and Content Type Hub

  • Article

Recently I wanted to manage a central set of document templates associated with content types across a number of site collections.  We also wanted to look at using content type syndication with content types that have a document template applied.  Document templates need to either be stored in the site collection where the content type is defined, or in <SharePoint root>/Templates/Layouts (_layouts).  By default when you upload a document template when you upload a template it gets stored to a hidden folder, _cts/<content type name>.  You can also deploy a template to this location as part of feature that deploys content types.  I did a quick experiment to figure out how these two models worked with content type deployment.

Centrally Managed Document Templates

In order to centrally manage a single instance of a document template, the template should be deployed to the _layouts folder.  By mapping a folder for the feature to the layouts folder for your document templates, the template will be deployed to the file system when the solution is deployed, and available to any site collection within the farm. 

  1. Setup the content type hub (see https://office.microsoft.com/en-us/sharepoint-server-help/manage-content-type-publishing-HA101631502.aspx).
  2. Create a feature that contains a content type with a document template, and the document template itself.  This SharePoint Developer Team Blog describes how to create a content type programmatically, associate a document template, and place the document template under a _layouts subfolder.  
  3.  Deploy the feature to the farm.
  4. Activate the feature on the content type publishing hub site collection.  Make sure the content type is setup to publish (see site settings->content type gallery, select the content type->Manage publishing for this content type, and make sure it is set to publish.

A couple of caveats. 

  • There is a hidden feature for managed metadata featuures on a site collection.  Some site definitions activate, others do not (for example, a blank site will not activate the feature).  See Content type publishing option missing from Site Collection Administration for more information on the feature to activate.  If you don't see a entry in the manage site collection settings for content type publishing then you probably need to activate this feature.
  • The solution must be a farm solution since files are deployed to the layouts folder.
  • The content type publishing and subscription process is managed by two timer jobs.  Both must run before a content type created on the publishing hub site is present on the subscribing sites. (content type hub, and content type subscriber (one for each web app)

Replicate Document Templates across site collections

If the template is instead deployed to a location within the site collection (for example the default location of _cts/<content type>),  it will be placed within the content database, and the document template will be replicated within each site collection.  For a blog on this approach, see the blog on managing document templates and content types with Office 365, Deploying a Document Template file in Content Type in a (Office365) Sandboxed Solution by Chakkaradeep Chandran. In the case of a no-code or Office 365 (or a sandboxed solution with an on-premise installation) you will need to deploy document templates to the site collection since you can't write to the file system. 

If the document template is deployed to the default "_cts/<content type>/" location then the document template will be replicated by the content type publishing logic with the content type. Since the document template is replicated, a new document can be created based upon the content type in the subscribing site. If an updated version of the template is uploaded, then the content type hub will re-publish the content type and document template to all subscribing sites.

Another option is to specify an existing document (which must be a location in the site collection). If an existing document location is selected, then the content type will be replicated refering to the location in the content type hub. However creating a new document based upon the content type in this case will fail since the publishing logic will not replicate the template file, and the content type will contain a reference to a document template that doesn't exist in the subscribing site.(unless some other mechanism also replicated this library). 

Conclusion

Generally I'd recommend avoiding using a library to contain the templates if you are using content type publishing. If you need a central repository and templates don't change often, then use layouts in which case a single copy of the template will be used by all site collections in the farm. If you can't deploy a farm feature, or you want to manage the templates through the UI rather than with a developed applications, then deploy the template to the default upload location (_cts/<content type>) rather than using a library to contain the templates, and the document template will be replicated by the content type publishing infrastructure. While I did not test the case of a cross-farm service, you'd clearly need to deploy the feature to all farms when using the layouts approach. I'd hypothesize that the content hub should still replicate templates in the case where they are stored to _cts location. 

If you want to deploy a content type across a number of site collections without using content publishing (recommended approach is using a site scoped feature), then the _layouts approach is the only solution to make it easy for maintaining a single document template used by all of the site collections using the content type.

Thanks to Andrew Connell and Rob Bogue for input.