SharePoint Content Types (CTs) have been a fundamental element in SharePoint architecture since they were introduced in 2007. They are also the cause of some divided opinions, in favour of (a) using multiple, ‘custom’ CTs to control content, or (b) minimising their use in favour of alternative options such as metadata choices.
A recent tweet from Nate Chambelain (@chambernate) read as follows:
You can have multiple content types in lists and libraries. They can all have unique metadata, templates, forms, retention policies, workflows, etc. Content types are EVERYTHING.
While CTs can do a lot as suggested by Nate, it is important to understand what they are, and what they can do, as part of an overall architecture model if you are planning to use SharePoint to manage records.
SharePoint administrators (and information architects and others) may have different views on this subject. There is, on one hand, the view that multiple ‘custom’ CTs are a good thing as they provide more control over content. On the other hand, there is the view that too many CTs are a bad thing because they are not easy to implement (see below for details) and it makes the environment harder to manage.
The key is getting the balance right. In my own opinion based on a decade of working with SharePoint, it is better to create custom CTs only where they provide specific useful functionality and otherwise using metadata columns and/or folders.
Content Types have been around since 2007
Content Types (CTs) were introduced in SharePoint 2007 (SP2007 usually known as MOSS2007), the immediate precursor to SP2010. CTs, it was said, would allow organisation to:
- Have multiple document types associated with a single library.
- Have a different document template in each CT.
- Have different workflows and metadata for each CT.
List CTs could also be used to capture different metadata in the same list.
What are Document Types?
Document types examples might include:
- Contracts
- HR document (e.g., specific to a staff member)
- Invoices
- Plans
- Minutes
Most organisations will have (and share) a relatively standard set of document types.
While it is tempting to create a CT for each document type (similar to the way some document management systems do this), in my experience this can create considerable overhead for very little benefit.
In my view, document types should only ‘map’ to custom ‘content types’ if there is a reason to use CTs for a specific purpose (see below for examples).
Otherwise, it is far easier and more efficient (in terms of management) to create additional metadata columns including, if required, a ‘choice’ metadata column to define the document type.
Every Content Type has a parent
Every new site collection includes a range of default CTs and each has a parent. The primary default CTs are:
- ‘Document’, ‘Folder’ (and, where enabled ‘Document Set’) for document libraries.
- ‘Item’ for lists.
- ‘Event’ (parent is ‘Item’) for calendars
Your starting point, when thinking about CTs, is whether you will (a) use the default CTs or (b) create custom CTs – or (c) a combination of both. Most organisations will have a combination.
By way of reference, we had 500 site collections and fewer than 30 custom CTs, each used for a specific purpose. We did not use the CT Hub but created CTs directly on the sites where they were required.
How many custom Content Types do you really need?
The answer is, ‘it depends’.
The case for multiple custom CTs:
- Custom CTs allows organisations control of specific types of content at a more granular level than the document library.
- Having multiple custom CTs requires more overhead to create, implement and manage. First, each custom CT must be created via Site Settings. In each document library setting where the CT is to be used, a setting must be enabled to allow management of CTs. And finally, each CT must be added to each document library (or list).
- Questions to consider: Who will enable the library setting then add each CT that is required? Who will manage metadata conflicts if different CTs use the same or very similar metadata? How will end users react to have to select a CT every time they just want to save a document (including via synced libraries in File Explorer)?
The case for fewer CTs:
- Fewer or more selective use of custom CTs allows organisations to manage content at the logical aggregation of a document library rather than CT-linked content within that aggregation, using custom CTs only where necessary. This requires less overhead to manage.
- Site Collection Administrators or Site Owners can create CTs when and only if they are needed.
- Site Owners (and end users) can more easily manage content within a document library by using folders and/or metadata to group content and/or apply workflows.
- Choice metadata columns (e.g., for ‘Document type’) may be a better option.
- Site Owners can create document libraries with names the comply with naming conventions and apply retention policies to the entire library.
The bottom line – just because you can create multiple custom CTs, it doesn’t mean you should. It is important to understand the broader architecture of the entire SP environment and what you are seeking to achieve.
As a general recommendation, I would suggest creating only the CTs that you really need (based on a content management design), and consider using separate libraries (or sites) and/or metadata to define content types. For example, consider having a single library called ‘Meetings’ or ‘Policies’ with useful metadata columns.
More custom CTs will mean a more complex environment to manage, especially from a records management point of view.
How are Content Types created and then applied
New custom CTs are created via Site Settings – Site Content Types.
As can be seen above, every new CT is based on an existing (‘parent’) CT that exists in a grouping of ‘parent content types’. For example:
- The ‘Document’ CT is found in the ‘Document Content Types’ group. Surprisingly that group also includes ‘Master Page’, ‘Site Page’ among others.
- The ‘Document Set’ CT is the only option in the ‘Document Set Content Types’ group.
- The ‘List’ CT is one of multiple options in the ‘List Content Types. It includes ‘Event’ found in calendars – ‘Event’ is the child of ‘Item’.
Once the new CT is created, additional columns can be added to it, including from the Managed Metadata Service (MMS), if used. The new, custom CT can now be added anywhere on the site.
Two steps are required to add a CT to a document library or list:
- Go to the library or list settings and click on ‘Advanced’.
- In the ‘Advanced’ section, click on the option to ‘Allow management of content types’.
Note that enabling this option has an impact on the ‘+ New’ option in the library ribbon menu – see below.
Once enabled, a new ‘Content Types’ section appears in the Library Settings, displaying all the CTs now available in the library. Only the standard ‘Document’ CT will appear and show as the default option.
Someone (SP Admin, Site Collection Admin or Site Owner) must now click on ‘Add from existing site content types’, and choose the CT to be added. This action could probably be scripted however it is a one-off event.
Once the custom CTs are added, another (but only one) CT may be set as the default. The others are visible by default but can be made invisible if required.
Any unique columns in any of the CTs will now appear in the ‘Columns’ section, showing the source of the column (‘Used in’).
Folders or document sets?
While it is possible to create folder-based CTs, with unique metadata, to group documents, it may be more useful to create document set-based CTs as these provide much more flexibility. Unlike folders, document sets also have a unique document ID (that same one that is applied to all documents in the library, with a different sequential number).
How CTs are used
Once they are enabled, the new CTs now appear in the ‘+ New’ drop down menu for the library. End users may now choose which CT they want to add to the library (or it may be the default).
As can be seen above, the option to create an Office Online document is no longer available. (These options can, however, be added back via the ‘Edit New Menu’ option, however there may be reasons not to want to allow this).
Each document-based CT includes the default ‘Document’ template. This means that if an end-user clicks a custom CT from the ‘New’ menu, it opens Word Online. Should it be necessary for the end user to, say, create an Excel document the following steps must be followed:
- Click on library settings
- Click on the custom CT
- Click on ‘Advanced settings’ (which will show ‘template.dotx’ as the default template)
- Upload a new document and choose the file – e.g., a blank spreadsheet with a sensible name, or a given template that must be used every time. Note that the template must be able to be opened in the online versions of the Office applications.
If the document library contains mandatory metadata, and the end user is working directly from the library in SPO, they will be required to add the mandatory metadata.
If the end-user saves a document to a synced library in File Explorer, and that library includes CTs, the end user will be asked to select the CT from a drop down list in a separate dialogue. If the CT includes any mandatory metadata, it will not be possible to add a new document via File Explorer.
What about retention policies?
The ability to apply retention policies in CTs is only available as an ‘auto-apply’ option to those who have an E5 licence. Essentially, when a new retention policy is created (based on a label that defines the retention options), it can be auto-applied to specific CTs. For more details, see this article by Joanne Klein.
What this means is that individual documents contained in the CT (not the CT itself) will be subject to disposal at the end of the retention period. As noted in my earlier post on managing retention outcomes, disposal may be automatic or subject to a review.
Specific use cases and careful consideration of the options and implications need to go into planning for the use of retention policies on custom CTs. While the option may appear to be a simple way to manage the retention outcomes of specific types of content, in reality it could be very hard to manage in large organisations, especially as individual documents are the subject of disposal, not the aggregation (CT or library).
Joanne Klein’s article above refers to a CT named ‘Contract document’. While this is just an example, most contract documents will be subject to disposal review ‘n’ years after the contract has expired. Therefore, retention should be based on a metadata column named something like ‘Contract Expiry Date’. Many organisations, in my experience, keep contract documents well after the contract expiry date. The use of retention policies on contract-related CTs needs to be considered carefully.
Where custom CTs could be useful
Custom CTs can be useful to manage ‘files’ within a broader grouping or aggregation. The following are actual examples from my organisation:
- To manage individual staff files (created as custom document sets), in a document library that is used to manage all staff files.
- To manage a collection of contract documents (stored within a custom document sets), in a document library (or libraries) that has retention enabled at the library level. In this example, folders would probably be just as suitable.
- To manage building/property documents (again stored within a custom document set) in one or more document libraries.
The primary reason that using custom CTs here is better than using simple folders is that the custom document sets can contain specific metadata that is needed, such as ‘Staff ID’ or ‘Staff Name’, ‘Building Number’ or ‘Building address’, or ‘Company’.
Conclusion
Content types are, indeed, a core part of SharePoint. However, unless your organisation is small or you only want to control selected content via the use of custom CTs, it may be easier and more efficient to minimise their use and use metadata choice columns instead.
Applying retention policies to CTs – assuming that is considered to be a viable records management option – is only available to organisations that have an E5 licence. This option should be considered carefully, especially the outcomes when the retention period expires.
Custom CTs can be very useful when used correctly. It is important to have a good understanding of how they work and where they can be applied most usefully. Otherwise, there is a high potential to add considerable complexity and management overhead to your SharePoint environment.
Records about the world 