In this series of blog posts, I’m going to look at maximizing SharePoint’s features and functions to fulfill your business needs. Initially, we’ll go over some of the basic features that are essential to configuring a sensible hosted SharePoint environment. As the series continues, we’ll take a look at some of the more advanced SharePoint 2010 features.
For now, a good place to start is with planning content types – and using them to store metadata.
What is a SharePoint content type?
According to Microsoft, a content type “… defines the attributes of a list item, a document, or a folder.” In Microsoft SharePoint, every list item, document, or folder is associated with a content type.
Reasons to use content types:
- Metadata
- Workflows
- Information management policies
For now, we’re going to look at using content types to store documents with associated metadata. In a future article, we’ll look at leveraging content types for workflows and information management policies.
When creating a content type to save metadata, you associate one or more columns to that content type. A user populates these columns with values when saving a document to SharePoint. These values are the document’s metadata.
What is SharePoint metadata?
Metadata is most often defined as information about data that is not necessarily contained in the data. A more succinct definition is: metadata is data about data.
It may sound cryptic, but it’s actually really simple. Imagine a music collection with a large number of antiquated CD’s. The music on the CD is considered data. So information about the CD is metadata. Common metadata for music is artist name, album name, and genre. Metadata helps us sort and categorize a large number of items. So if we’re looking for a specific CD, we can sort by genre and then by artist, and then to album name.
In regards to documents that are stored in SharePoint, metadata can be used to assist users in identifying specific documents. Document libraries often store a large number of documents, sometimes in the thousands. Without SharePoint metadata, finding a specific document can be a tiresome, tedious, and often futile exercise. Indeed, without proper planning and use of metadata, it can become the proverbial needle in a haystack.
How to leverage metadata when locating SharePoint documents
There are two primary ways to leverage metadata when locating documents.
The first is by using search. As you can see in Example 1 below (click for larger image), I wanted to locate all documents from a specific vendor, fpweb.net.
Example 1
The documents in this example are not full-text searchable, so SharePoint search is unaware of the contents of the document.
However, when the documents were saved to SharePoint, Fpweb.net was entered in the VendorName column. Thus, when I run a search, I can see all documents pertaining to this particular vendor.
Another way to use metadata is with the view of the document library. You can specify columns to display in a view.
These columns can be sorted and filtered. As you can see from Example 2, I have filtered the VendorName column to Fpweb.net.
Example 2
Planning content types
Now that you know why you should use content types with documents saved to SharePoint, let’s take a look at creating a couple of content types. Before we actually create them, however, it’s always a good idea to plan. Planning your SharePoint taxonomy before configuring is essential to a successful implementation. If you don’t plan ahead, you’ll be sorry… I guarantee it.
An important thing to understand is content type hierarchy. Because content types have a hierarchal structure, it’s possible to share the settings from a parent content type to a child. Sibling content types cannot, however, share settings.
Using a parent-child content type hierarchy is useful if you are creating multiple content types that will share the same column. Consider an accounting scenario:
You want to save both Invoice and Purchase Order document types in the Accounts Receivables document library. When a user saves a document to this specific SharePoint document library, they can specify which document type it is.
You could make two separate content types… Or, because much of the same metadata needs to be captured for both types of documents, you could create a parent content type that consists of columns that are to be shared. You would then create two separate child content types inheriting these columns from the parent. In the child content types you would create columns that are unique to the type of document.
Parent-child content type hierarchy: a closer look
I have determined the following columns need to be associated with both the ARInvoice and ARPurchaseOrder content type: (These columns will live within the parent content type.)
- VendorName
- PONumber
- PODate
- POAmount
Furthermore, the child ARInvoice content type will need InvoiceNumber and InvoiceDate columns while the child ARPurchaseOrder content type will need ContactName and ContactPhone columns.
The following is a graphical representation:
Content Type Hierarchy
The columns for the AccountingBase content type, represented in gray, are inherited by the two child content types. These content types will also have their own unique columns.
Leveraging inheritance can save you effort and headaches for two primary reasons.
- It simplifies the creation of content types. It may not seem like it in this example because you have to create three content types (the base and ARInvoice and ARPurchaseOrder) rather than two. However, you may also need to create a document library for Accounts Payable and create two more similar content types. You can leverage the base content type to simplify the process.
- Modifying content types is easier. For example, if we wanted to add an information policy to both the ARPurchaseOrder and ARInvoice content type we could add it to the AccountingBase content type. If we wanted to add an additional column to the ARPurchaseOrder and ARInvoice content types, we would only need to add it to AccountingBase.
That’s it for now, stay tuned for part two – “Creating the Content Type.”
