Content Types are a very powerful way to express the concept of “document types” or “business objects” in SharePoint.
In the Notes world, it is quite common to design an application that has multiple types of documents in it. Even though Notes databases are unstructured and (by design) lack any type of schema, good Notes developers usually adopt certain patterns and practices that impose some order in their applications and usually this includes establishing distinct, meaningful document types.
From a development perspective, this is largely driven by the different Forms used to create Notes documents. A great example of this is a standard Notes mail database, which has Memos, Tasks and Calendar Entries. If you want a business application example, think of Customers, Customer Contacts, and Sales Reps in a CRM database. Each of these “document types” has different fields in it and each is created with a different Form.
While Notes Forms has several other uses (for example, to display a pop-up dialog), the Form used to a create a document becomes the de facto “document type” in most cases. An application may contain one or more Views or Folders for each document type (for example “All Tasks by Priority” or “Open Tasks”). But it is also common to design a View or Folder that shows multiple document types together (for example showing Customers and Customer Contacts together in the same view).
A common variation on the above pattern is to use different forms to express extended document types (what object oriented developers would call “sub-classes”). An example of this would be an application that had both Customers and Government Customers. While a Government Customer is a type of Customer, it has additional fields and may have additional data validation rules, different security, etc. You could easily imagine a View that shows “all customers” together without making any distinction, but when you opened a Government Customer record you would see something different than if you opened a “plain” Customer record.
The notion of defining different document types is not limited to Notes applications. QuickPlace sites have several different default “Page Types” and users can create their own custom Page Types with additional fields. Similarly Domino.Doc libraries can be extended with both custom Document Types and custom Binder Types.
So how do these concepts translate to the SharePoint world and how do you you deal with them when migrating?
When migrating a Notes application, a QuickPlace site or a Domino.Doc library to SharePoint, developers typically do one of three things. Note that each of the following choices apply equally well whether you are migrating to a SharePoint List, Document Library, or an InfoPath Forms Library:
- Split different document types into a different Lists. You could easily run one migration job that moved all Customer records to one list and another job that moved all Sales Rep records to a different List in the same SharePoint site. This would be a particularly good idea if, for example, you wanted Customers to have a “Rep” field that was a Lookup field from the Sales Rep list. It is less clear, however, that it would be good to split up Customers and Government Customers this way as you probably want them to stay together. Notes Migrator for SharePoint allows you to select records by View or by Formula; if you can not find a View that selects the documents you want you can use a Formula such as: FORM = ‘GovernmentContact’
- Merge different document types into a single uniform List schema. For example, you could migrate all Customers to a single Customers list and discard the extra fields that was in Government Customers (a “least common denominator” approach). Or you could include all the “government” fields in your new Customer definition and just leave these blank for the records they don’t apply to (a “grab everything” approach). You might even add a new “Customer Type” field that recorded whether or not it was a Government Customer in Notes.
- Use Content Types. The pattern of using Forms to express document types in Notes applications maps almost perfectly to SharePoint “Content Types”.
There is a lot of information on the web about Content Types. I like Andrew May’s blog [link]. The Microsoft SDK documentation [link], which can be pretty intimidating to read, introduces Content Types this way:
Content types, a core concept used throughout the functionality and services offered in Windows SharePoint Services 3.0, are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way.
One of the reasons Content Types seem so intimidating to new SharePoint developers is that they are used for so many things. Not only are they used to express which document types contain which fields (the important part for people migrating content), they can also be used for the following:
- Custom user interfaces
- Templates for creating new documents
- Workflow rules
- Microsoft Office integration
- Inheritance from “base” Content Types
- Reuse across multiple lists in a SharePoint site
The good news is that using Content Types for simple things (i.e., defining multiple structured document types in a single list) is actually pretty simple. In spite of what some of the literature implies, you do not need to be a developer or create features or even use XML to create document types. I believe that as people come to understand them better, they will become more widely used.
Notes Migrator for SharePoint has the ability to set content types in migrated documents based on the Form that was used in Notes, or whatever other criteria you want to use. Part 2 of this article will discuss how we make that happen and will include a working example.