Leveraging content types in SharePoint ECM projects
Content types can be a confusing, contentious and scary topic for large scale ECM Projects on the SharePoint platform and I’ve seen it all. I’ve been witness to projects where every document type in a department had its very own content type, resulting in hundreds of content types and a complex, confusing and largely unused solution. I’ve also had clients that didn’t want to leverage content types at all. The right answer is, of course, somewhere in between.
Content types and their associated metadata do add a tremendous amount of value to large scale SharePoint ECM projects. They can improve search and findability, enable workflows and even automate compliance. While there isn’t a one-size-fits-all design pattern that suits all organizations, I hope this blog help shed some light on how to approach this fundamental SharePoint ECM topic that is just as much an art as it is a science.
User experience trumps all
User adoption is critical to the success and typically the hardest part of any ECM program. I’ve found it best if we have the mindset that we are creating business solutions with the end users and for the end users. We want SharePoint to add value to end users' jobs through collaboration, proper document management, and workflow while at the same time meeting our goals around records management and compliance. I have found that by putting the user experience first and foremost, everything else tends to fall into place or, at least, becomes a little easier. So when your getting lost in the details of designing content types, be sure to remember this crucial objective.
How many content types should you have?
There’s no single right answer and since every organization is unique, it is hard to say exactly how many content types you’ll need. In general, you’ll want to be thoughtful and deliberate around the creation of content types trying to keep the total number of content types to a minimum, while at the same time attempting to meet end user business needs and driving compliance in the background.
It has been my experience that a couple of dozen core content types can be shared across the organization (e.g. policies, procedures, contracts). Each department or function may need another dozen or two content types that tackle the core areas of their work. For example, you’ll likely create an invoice content type for the finance department and employee documents content type for the human resources department.
That being said, in many cases content types are not needed so don’t force the creation of content types just for the sake of creating them. Larger more complex organizations might need more content types, and smaller organizations might need less. When it doubt, consider your goals of user experience and compliance.
How detailed should content types be?
Once users grasp the idea of content types, they can have a tendency to over-design. Let’s take invoices as an example. One might be tempted to capture the following about each invoice
Vendor
Date Received
Date Due
Invoice Amount
Payment Status (paid, unpaid)
Purchase Order
Processed by
Comments
At first glance, this may seem like a good content type that will provide functionality to the end user, but in practice, this is likely too detailed a content type. Users will be a little annoyed at all the fields they have to fill out each time they upload a document as seen below.
Likely too many METADATA fields
As a general guideline, you should minimize the number of metadata fields that you are expecting end users to fill out. Typically going over five will start to frustrate end users and potentially lower adoption. There’s a quote from Forrester Research that nicely captures the outcome if we're not careful:
“It was so unusable. Eleven metadata fields! We just stopped using it altogether and started managing our documents on our workstations, another file share, anything to avoid having to use this system.”
- Forrester Research
Metadata, especially those metadata that we are asking end users to fill out, should provide value to the end user. It should help them search, sort, filter or group in likely scenarios. Let’s walk through a couple of the fields above in more detail and then refine this content type to be more pragmatic:
Vendor
It is indeed likely that end users would want to search, sort, filter and group on the Vendor field. It will enable them to create views on the library that will make the documents easier to manage and improve the overall user experience. Therefore, the Vendor field is likely a piece of metadata that we would want to capture. It is also contextual information that the user likely already has. That is to say, they do not need to stop and open the invoice to find out the vendor name.
Invoice Amount
It is unlikely that the invoice amount is something that the end user would want to search, group or filter. One could argue sorting by invoice amount, once in a while, but in practice sorting by the vendor, payment status or date is far more likely.
The Invoice Amount is something that the end user would potentially have to stop, open up the document, write the number down, and then continue uploading the invoice into SharePoint. This may not seem like a lot, but adding 20 or 30 seconds for each document you are uploading when you are processing hundreds or thousands will frustrate users.
The last thing about capturing the invoice amount is that end users are unlikely to trust that the number they see in SharePoint as the actual invoice amount. It has been my experience that when end users are searching for a particular invoice, they are more likely to open up the document to see all of the official details, rather than trust the invoice amount entered as metadata.
Walking through each of the fields and thinking critically about each one, as we did above, I would likely end up with a much simpler content type that only captures the Vendor and the Payment Status (in addition to the out of the required fiends). There is, of course, no single right answer here that would meet the need for every organization. If the end users want to capture the invoice amount, then go ahead and add it in, but be sure to think carefully about each element of metadata and follow up with them after they’ve been using it for a week or two and make any refinements that they need.
An invoice content type that has less friction
What about meeting compliance needs?
If you are doing a large SharePoint ECM project, it is likely that you’ve sourced a records management add-on. My favorite, by a long shot, is Collabware. Collabware adds hundreds of items of functionality that turns SharePoint into a compliant RM system. In the context of content types, Collabware was designed to place content into the proper record category automatically, based on content type, metadata or some combination thereof. While the record category that Collabware leverages is a site column in SharePoint, it is typically not metadata that you want end users to fill out themselves or even see. You can typically have Collabware inspect the details of a document and place that content into the right category for you. Once in a while, I’ve had to go to add an element of metadata to a content type solely for driving content into the right category, but it does not happen very often, and it is something I try to avoid. If you are focusing on meeting the needs of the business and a great user experience, then more often than not you’ve likely captured enough information to drive compliance automatically. As a side benefit, you are also likely to increase the accuracy of your record categorization!
Archival considerations
Once the end user no longer needs content on a regular basis, you are likely better off to archive it and get it out of the way, so that end users only have to deal with most relevant content on a daily basis in their team sites. In SharePoint land, this means sending it off to a record center – a SharePoint site template designed for long-term storage of large amounts of content. Taking the example of Collabware, it will, if you ask it too, provision a record center for a given record category. How does this affect our content types you ask? Well, depending on how you are using your file plan you may, for example, want to separate out and secure the content based on department. If all departments are sharing the contracts record category, but you need to ensure that each department can find their archived contracts while not being able to see other departments’ contracts, you could leverage the content type organizer functionality in SharePoint and separate and secure them based on department. While I would not advocate having every user enter the department for every document, you could likely set the department as a hidden field behind the scene as a column default value setting, if you foresee the need to separate content in the archival space by an existing metadata field.
Additional thoughts
Avoid default values
End users tend not to change default values. I will only leverage default values if it is the only option for a given library. For example, if you have a document library for each employee, and you want to capture the Employee ID, I would set the default value for the employee ID on each document library.
Avoid edge case metadata
Once in a while, I’ve had clients that wanted to add some metadata to every content type– just in case someone needed it. For example, an author field to capture the original author if the person uploading the content into SharePoint did not create the document. Unless you need this to meet some strict compliance needs, I will avoid these types of fields as they likely won’t be used very often and would just complicate things for the average user.
Automate!
The more you can automate the more value your solution is adding to the organization and the happier the users will be. If setting metadata can be automated through workflow, default values, or scanning solutions like PSIGEN, I would take the opportunity to do so! Also if metadata fields can be automatically captured, then I would be more likely to capture the information that I wouldn't want to if the end user had to manually fill out the fields.
Get feedback and make refinements
Often we will not get things perfect the first time around. There may be an element of metadata that we’ve added, and it just isn’t needed or perhaps we missed an item of metadata in our initial round of requirements. It is important to follow up with your end users once they’ve had a chance to use the solution for a bit and plan to make some minor enhancements, as chances are they’ll have a couple of asks.
