Centralised document template management in SharePoint

The idea of having a centralised document templates library in SharePoint has much to recommend about it. It makes sense to push standard corporate templates from one central location to ensure that everyone within an enterprise is using the same single set of templates, and having them in one location also helps to provide ease of maintenance and updates when required. However, there are a number of drawbacks and pitfalls to this approach, all as a direct consequence to how they must be set up to work in SharePoint. This article will provide some information around the drawbacks, so that users can be better informed if this sounds like an approach they wish to adopt.

In my scenario, I had multiple site collections for a number of collaboration team sites, and decided that each site would ship a standard set of content types, with each content type tied to a corporate Microsoft Office document template. I had a root site collection, in which I created the centralised “Document Templates” document library, where I uploaded the corporate templates.

Using the following article as a guide, I configured the Templates document library with the following settings. Note, this is the only way to get the templates working correctly when hooking them into standard document library later on.

1. Created a number of site content types – for example one for a corporate Word template, one for Excel, one for PowerPoint and so on

2. Added the site content types to the Document Templates library (they create local list versions of the content type)

3. Edited the properties of each document template in the templates library, to point each template to it’s appropriate content type

4. Edited the site content type under Advanced Settings and pointed the Url of the document template property to the location of the template in the Templates library

Following this, I could then create other standard document libraries where I wanted to make the templates available under the New…document Ribbon options. All I needed to do was to have the same document template-aligned content types added to my other document libraries. So far, so good.

However, as the templates were rolled out to the site collections and became used over time, a number of issues have surfaced that has severely undermined my confidence in the solution.

Issue 1: Use of person or group fields in the site content type metadata

The templates were configured to expose a “document owner” field that the end user could assign from the document information panel when the document was being saved for the first time. This was set up as a mandatory field, so the user had to set it first time round. Unfortunately this led to a rather bizarre outcome. Whilst setting ownership to their own SharePoint account via the document information panel, when it saved and refreshed in the library view, it was showing up as another user entirely! After some painful troubleshooting, it was discovered that because the centralised templates library was in a separate site collection to the one where the document was being created, the hidden user information tables (the place where the user account is referenced via the person/group metadata field) in both site collections had separate sets of Ids for the same user account. So opening a document template from the original centralised templates location could not be supported in this scenario, and I had to revert to site collection specific versions of the templates. A major plank of the approach to centralise document templates was removed from my solution straight away, rendering the endeavour pretty fruitless. Of course, the workaround is to not use person/group fields in you custom content types, but that was just not an option for me.

Issue 2: Use of localised metadata default values

Another major drawback of the centralised approach is when using them in conjunction with the requirement to have library-specific metadata default values. Going back to our previous setup, one of the fields in our custom site content types was a choice field, which presented values that had to be one thing for a certain set of document libraries, and another for a different set of document libraries. This just won’t work properly if your content types are added to a local library but are using centralised document templates in another “document templates” library, where no default values are set. When you create a new document in a local library based on one of your document template-aligned content types, it hooks into the content type that the template is assigned to in the document templates library, not the local library.

It is possible to workaround this disappointing, though not unexpected outcome, (given how the document templates have been set up above), by instead setting library specific default metadata values not at the local column level, but at root folder level, by configuring the default value using the “Set column default values” management screen under list settings. This though again cranks up the management overhead, and make the overall approach even less attractive.

All of this general dissatisfaction is compounded if you want to add any new library specific metadata in addition to that provided by the content type. So for example you might want to add a list column that is specific to the library you are in (a not unreasonable requirement). However using this approach in a library with centralised document templates tied to content types will again raise issues, in that if you create a document via the “New document” ribbon options, the additional metadata will not be picked up and presented in the document information panel (as they are not part of the content type that is aligned to the document template!) If you make your new field mandatory, and try to save the document, the document validation fails, and the new field does then appear in the document information panel the second time round, which from a usability perspective is pretty poor indeed.

So there you have it, a good idea becomes a minefield of issues when implemented. I’ll let you decide whether the approach is worth the nasty side effects.