Content Types
It
is often difficult to find related information when you are searching
through a large repository. For example, let’s assume that you need to
create a project plan for a new project and you know that there have
been other projects similar to yours in the past. In a portal with many
project team sites, it can be challenging to find all of the project
plans. Content Types in SharePoint helps simplify this task. If you
define “Project Plan” as a Content Type, you can then find all project
plans in your portal easily with a single search. Content Types also
let you associate specific Site Columns with different types of
content. For example, you can associate an Effective Date with a Policy
but not with other types of documents. If you share and manage the
Policy Content Type across your entire farm, you can ensure that all
Policy documents, created in any Site Collection, will have Effective
Date as an attribute.
A Content Type contains these elements:
Metadata (Site Columns).
The attributes required by a Content Type are metadata about the
content that can be used for categorization. You cannot define default
values for Columns in a Content Type, just which properties or Columns
are associated with the Content Type. The values for a particular
metadata Column are defined for the Column, not the Content Type. If
the values for a particular Column are unique to a Content Type, consider defining a separate, unique Column that is associated with a particular Content Type.
Document template.
Document templates can be used to create files with predefined styles
and boilerplate content. You can assign one unique document template to
each Content Type.
Custom “forms.” Specific New, Edit, and Display forms can be defined to use with a Content Type.
Workflows.
Some Content Types have a consistent process that can be assigned for
approval. For example, all Status Reports may have to be routed to the
project manager before they can be published on the portal. A workflow
can be associated with a particular Content Type. Workflows can be
triggered automatically based on a specific event or manually with a
user’s action.
Information management policies.
Your organization may have rules about how particular Content Types
should be managed. This is particularly useful for records management.
You can associate policies with a Content Type to manage
characteristics such as retention period.
You can also associate workflows, properties,
templates, and policies directly in a list or library. However, when
you associate these items “locally,” they are not reusable, even within
a specific site.
Content Types are organized in a hierarchy that
allows one Content Type to inherit characteristics from another Content
Type in parent-child relationship. For example, while a memo is an
“instance” of a document, if your organization wants users to leverage
a standard template when creating a memo, you will want to create a new
“Memo” Content Type as a child of the parent “Document” Content Type.
The Memo Content Type can inherit all of the properties of the Document
Content Type but can leverage a different template.
As a general rule, define Columns and Content Types
at the highest possible level in your solution so that they are
reusable and “manageable” across the entire solution. Depending on your
role, you can define Content Types at the site, Site Collection, or
enterprise level. Once you define a Content Type, it is available in
that site and all subsites.
If you want a Content Type to be available to a specific site (and its subsites), define it in the site Content Type Gallery.
If
you want a Content Type to be available to all sites in a Site
Collection, define it in the Site Collection Content Type Gallery.
If
you want to create a Content Type to be used across your entire form or
across multiple Site Collections (at the enterprise level), define a
Site Collection to be a “Content Type hub.” The Content Type created in
the hub can then be associated with each Site Collection using the
Managed Metadata service. Once an enterprise Content Type is published,
it can’t be changed within the local Site Collection.
As you might imagine, if you are going to define
metadata at the enterprise level, you are potentially introducing the
need for a new governance role—an enterprise data or content architect
or metadata planning group. Someone (or some group) in the organization
should be responsible for planning and managing enterprise-level
Content Types and other shared (managed) metadata. This does not have
to be someone in a full-time job (though it may be in large
organizations), but the role will clearly need to be defined in
someone’s job description.
There is as much art as science required to
determine what Content Types you need in your solution. Consider the
following when you are planning Content Types for the enterprise, Site
Collection, or individual site:
Does this type of content have unique requirements based on the Content Type elements listed here?
Should
this Content Type be available across the entire enterprise or in one
Site Collection or one site? For example, if your organization has
implemented a records management policy, you may want to add a Records
Retention Code to one or all enterprise document Content Types and make
it a required field. This will ensure that users will assign a Records
Retention Code to all documents.
Would a
user want to search for this type of content uniquely? For example, if
you think that your users might want to be able to search for all forms
in your portal, no matter who publishes the form, you will want to
create a unique Content Type called Form. However, if personnel forms
have a different template or workflow than accounting forms, you will
want to create a “parent” Content Type called form and two “children”
Content Types, perhaps called Form-Personnel or Form-Accounting.
Many
users find that having too many unique Content Types creates more
confusion than value. Try to keep the number to less than 10 to 15 if
you can. A smaller number of Content Types is probably better,
especially for document repositories.
The
Content Types that you define will be very specific to your
organization; however, here are a few examples to consider in addition
to those provided out-of-the-box. This list is not meant to be
exhaustive, but it will give you a sample of some Content Types other
organizations use:
Article
Brochure
Case Study
Form
Job Description
Lesson Learned
Policy
Project Plan
Trip Report
Figure 1 shows a simple example of how Content Types can inherit metadata (Column) values from their parents.
