Prior to reading this article, you may wish to read its predecessor, How to Create SharePoint Content Types. The purpose of this post is to have a more in-depth discussion on Content Types for those who are having difficulty grasping the concept, or for those who wish to gain a deeper understanding of how to leverage Content Types. Since Content Types are an abstract idea, some may have trouble figuring out exactly how to design Content Types, and what they should be used for. Hopefully by the end of this article, you will have a more solid grasp of this important tool.
We will start with the most basic example of a Content Type: the Document. This is the default Content Type for all Libraries in SharePoint, along with the default metadata (note that Record Classification has been added by CLM).
So the simplest description of a Content Type is this: a named item (Document) that carries metadata columns (Name, Title, Record Classification).
If we go back to our computer, we will find that we have the same item. A Document on our desktop has a Type (as displayed by the Icon) and a Name (user input information). But this isn’t the important information about our Document. The important information lies inside the Document, the words that we have typed there. The only reason our Document has a Type and a Name is so we can find it later!
And so, we have our full description of a Content Type, and a purpose for its existence. It is the item that holds our information, and it has some information on it so we know what it is. To use a simple metaphor, the Content Type is the envelope that holds our letter. The letter is the important piece, but the envelope carries information that is helpful, like who this letter is from or who it is to. Metadata, and through it, a Content Type, is information that describes a document.
Now that we have a simple concept of our Content Type, we can start making it more complex. Content Types can carry many different types of information, called metadata columns. The Document shown above has only three metadata columns. They are helpful, but there is so much more that we can add.
In order to do this, let’s start with a more complex piece of information: a receipt. We deal with receipts all the time, but we never closely examine them for all the information they really contain. Here is a list of all the metadata that could be pulled from a receipt:
All of this information is useful, and if you collect enough of this information, you can make some large generalizations about most frequented locations, most frequented time, spending habits of customers, etc.
Hold on one moment, you may say. That's not the metadata of a receipt! That is the receipt! The list above contains every piece on information on a receipt. Why even bother having a receipt document when you can capture all of the information in its metadata? In some cases, you would be correct in saying this. In other cases, it would be incorrect to assume that you could capture all the contents of a document within its metadata. It is simple for something like a receipt, but what about a more complex document? Take for example, a contract.
Let's try and think of all the metadata that could be used to describe a contract:
Here is a good representative of the metadata information that can be used to describe a contract. Now look at this set of metadata and compare it to the set of metadata for a receipt. You may notice some strong similarities. They both have organization names and addresses, dates, monetary amounts, and items "purchased". In the case of the contract, instead of goods, the organization is purchasing services. The reason that the receipt and the contract have such similar metadata is because they both are of a single type: a financial document, a transaction document, an agreement. There are many different names for this type of document, but they all share the same set of basic metadata:
There will be some variation between different types of transactions, but the main metadata will always stay the same for these documents.
Now that we have recognized this fact about transaction documents, is there any way we can leverage this information? It is this exact question that leads us back to Content Types. If we are able to make up a general set of metadata that represents many different types of documents, we can capture that set of metadata in a Content Type, and make it available to different user groups to use. The legal team can use this Content Type when drawing up an agreement, and the financial team can use it when selling or purchasing goods, and the administrative team can use it when contracting out services.
This is an important point to grasp when understanding Content Types: Content Types can be used for many different document types. As long as the metadata columns can be used to describe the document properly, the content of the document can be anything. It could be as short as a receipt, or as long as a hundred-page legal contract. The only thing that is important when building a Content Type is determining whether or not there is enough metadata to differentiate the document from others. When the legal team is searching for an old agreement, they only need to know these few basic pieces of information about the document, rather than specific information about where the document is located, what the document is named, etc.
Now that we have a good idea of how you can re-use the same Content Type for different documents, let's move deeper into Content Type metadata.
Metadata is a useful piece of information that can describe a document. But what if we have a piece of metadata that is common to many different types of documents. For example, let's take address. Now, address in a legal sense is more than just a street number and name. It also can include a roll number, lot number, block number, and a district name. But in the end, most addresses can be boiled down into the roll number, which is a combination of many of the other pieces of metadata into a long numerical string. The roll number is the most common way to look up information on a property, because it is a piece of metadata that identifies it exactly, without capturing other documents that are unrelated (for example, looking up by street name can be difficult).
We have identified a central piece of metadata, the roll number, that can be considered the most useful piece of metadata. Now, because this piece of metadata is so useful, it is best to attach it to many different types of documents. For example, the roll number can easily be applied to a Deed. The roll number would also be useful when describing a Building Permit. These are all basic examples. But you could apply the roll number in many different places: engineering documents, electrical plans, fire inspection reports, police reports, tax returns, etc. There are so many documents created that deal with a specific location that a municipality collects. Each individual document type may have been created for a different purpose and have a different set of metadata, but they all have in common this one metadata column. If you mandate a procedure that requires everyone creating these documents to add the roll number, you have created a huge database that can easily be searched by this single metadata value.
This is the value that comes from being thoughtful about what metadata columns you decide to create and track, and which Content Types you attach this piece of metadata to. The central point to grasp here is that a single metadata column can gather together many different types of information.
To sum up everything, there are three central points to take away from this article:
Using these three ideas, you should be able to come up with a set of metadata that will allow you to track your documents effectively, and a set of Content Types that will be useful for the many different user groups of your organization.
To read more on Collabware CLM and all its features, download our Collabware CLM feature sheet & brochure:
