The other day I decided to start a power user best practice series.  I started with site columns and now the next logical step is content types.  I have found that many times experienced users don’t realise the importance of a properly setup content type.  Because of this, they often are recreating the same data, having to redo the content types  and in some cases blow them away and start over (both of which are a real pain if the CT is already being used).  The intent of this post is to cover the best ways to create your content types.

SharePoint Best Practices – Content Types

Planning

The first step to any content type design is to plan it.  You need to work with the users of the site\list\library on how they organise their data.  What data they need to track and find their data and\or documents and then build accordingly.  Don’t add columns that you think they will need.  If they wish to add more down the road that can easily be attained.  Too many metadata fields in one content type can become daunting to the users when adding data or uploading documents.  Determine fields that need to be mandatory.  A good rule of thumb is never go beyond five metadata fields that are mandatory.  You will quickly find that users will ignore them or simply not know all the fields.  In a list, this means the data doesn’t get saved, but in a document library it means you have a lot of documents that only the uploader can see.  Those documents will then have to be cleaned up by the uploader(s) or the admins of the library.  Planning ahead will help to ensure the users are getting exactly what they need and proper use will occur.

Base Content Types

If you are just building a single list or library and only need to track a few fields of metadata then you just need to create the content type, add your columns and update the list.  However, more often you are going to be creating a solution with multiple content types.  When this happens you need to consider a base content type.  Once you have completed your planning and determined the metadata you need to track; review it and find any common fields that exist in all of the content types.  These fields will make up your base content type.  Remember that every new content type needs to inherit from a parent.  Having a base content type allows for a few things.

  • Quicker creation of child content types – Suppose you had to create 5 different content types for your solution.  Each CT required around 10-12 site columns.  Well creating each content type is going to take time as you will have to add each of those columns over and over again.  But suppose each of your CTs had 7 fields in common.  If you create a base content type with the 7 common fields and then make that the parent of each of your specific CTs then just creating the new content type already adds 7 columns you don’t have to worry about.
  • Easier to update with common fields – I can guarantee anyone creating solutions in SharePoint has had this happen.  “You know that multi library solution with all those different document types you created for us?  We forgot we have to track some other data in all of them”. So now you have to update all of the CTs you created one at a time.  However, if you created a base content type then you simply need to update the base once and all children based off of that CT will now have that new field(s).  Easy Peasey.
Content Type Groups

Organising your content types into groups can be important.  If you are creating a full solution that has multiple content types added to it, then yes put them into a group that just makes sense.  However, if you are simply creating a CT for a library or a list and the business doesn’t expect there to be any further need for CTs then I would actually just leave them within group the parent exists in.  For example, if you are creating a single document content type and that’s all the business needs, then just leave the group as Document Content Types.  This way you aren’t adding a bunch of extra unnecessary groups in you list that you will need to track down for updates.  Remember, you can always update the content type later and give it a custom group should the business needs change.

Content Type Hub

The content type hub is a great tool for making your site columns and content types available to all your sites.  However, it can be used incorrectly.  You want to avoid using the CT Hub to push out your columns and CTs too much.  Even if you are wanting to share a content type across many sites or even site collections, don’t use the CT Hub.  The CT Hub should only be used for content types that need to exist across the entire organisation.  For example, if your organisation needs to track the security level and organisational codes for all of it’s documents no matter where located, then you can create a base document type in the CT Hub that contains these columns.  Push it out to your organisation and from there, any document based content types can inherit from that top level one ensuring the required data is tracked.

Creating the Content Type

Unlike site columns, you don’t have to worry about the initial name of content type.  There is no internal name field to worry about.  There is a name field which is simply the display name field.  However instead of using an internal name the content type gets an ID based on the parent content type.  Using PowerShell you do have the option to set that ID (coming later), but it isn’t terribly important as there are many methods to get a content type by the name AND the ID.  My suggestion when creating the content type is to first plan out your metadata…. actually, read my previous post on site columns.  Once you have your site columns created, add your content type.  Add your site columns.  Do not set your column requirements (optional, required, hidden) unless they need to be set for every use don’t set it at the top level.  Yes, you can modify it at the list level, but leave that for the mandatory/hidden settings needed for that list.

If you have any thoughts on this please leave me a comment.

 

Thanks for reading!