Supporters of End User
Web

Define Content Types for Records Management - Part 1

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.
Categories:MOSS; WSS; 2007; 2010; Content Types; Site Manager/Power User; Metadata; SharePoint Designer; Workflow; Solutions with Tools; Content Types for Records Management

 

In the previous article we set up our architecture for our records management solution and now we start the process of defining our Content Types that we will use.

Content Types are really the building blocks of any Enterprise Content Management solution within SharePoint, both from a document management and records management perspective. However we will be specifically concentrating on new functionality in SharePoint 2010 and defining our Content Types with Records Management in mind.

When designing Content Types there is a fine balance between being compliant and creating a solution that will engage users.  Content Types, in the form of documents, tasks, calendar entries and other list items will be the main way users will create content that will be declared as records. Some careful planning and thought can ensure that you build a solution that works great for users and Records Manager’s alike!

Content Types the Building Blocks

Content Types really are the building blocks to any good Records Management solution for a number of reasons:

User Interaction

A Records Management solution is only as good as the engagement that it provides for users. Put simply you will never be in compliance, regardless of how many certifications your Records Management platform has, if users choose not to use the system.

Users will perform actions on content as part of their daily activities. You need to make sure that you define your Content Types in a manner that is appropriate to your business for maximum engagement for users.

This means correct naming, metadata, information architecture and other elements need to be carefully planned.

Routing

Routing of content through various disposition cycles is very much dependent on the Content Types defined.  Regardless of which approach you choose (In-Place Records Management, send to Records Centre and then route to a file plan, or a combination) there are certain configuration options that are available only at the Content Type level.

For example if using an In-Place Records Management approach where records will be managed in the location they are created you have to be aware that Information Management Policies will need to be attached to the content type (there is an alternative way but it’s painful).

This limits us because we cannot attach multiple Information Management Policies to a content type and then choose, based on metadata, which retention schedule will occur when using the In-Place model.

The only solution to this is to define multiple Content Types with different retention schedules but is this the best approach? These are some of the issues we will discuss.

Control

The aspects of controlling and defining Content Types has been made a lot easier through a number of new features in SharePoint 2010, most notably through the Managed Metadata Service and Content Type Publishing.

This allow us as Records Managers to be able to centrally define Content Types complete with an associated taxonomy, workflow and retention rules from one central location and then push these Content Types out across every Site Collection or even cross farms! For me this is THE biggest evolution in the compliance aspects of SharePoint 2010.

What makes up a Content Type?

From a purely Records Management Perspective let’s have a look:

Metadata

Metadata is used for many things but in our scenario we are going to use Metadata for the following:

  • Routing of content to a file plan node based on metadata – we can route based on metadata to our file plan using the Content Organizer.
  • The ability to set default metadata at the document library level. This provides two interesting scenarios. Firstly we can make the process of attaching metadata easier for users by doing some of the work for them. Secondly we can now attach additional metadata automatically when a piece of content is routed to a file plan location. Neat!
  • Search
  • File Plan Navigation through Metadata driven nabvigation

Information Management Policies

This is the main way we define retention within SharePoint 2010. Information Management Policies are attached to Content Types or defined on Folders which will then be triggered when the piece of content becomes a record. When this occurs our content will go through the various stages that we define.

There will be a lot more on IMP’s in the next few articles as this is so important for Records Management.

Workflows

One of the great things about SharePoint is the ability to attach a workflow to a Content Type. In our case we are going to use the Disposition Approval workflow that comes out of the box! Very simple but very powerful, especially since we can use SharePoint Designer for some great customizations.

Content Type Tips

In terms of defining Content Types for Records Management here are some rules that we will use next time when we start defining our Content Types:

Use Content Type Publishing

Content Type Publishing will give us the ultimate control over all of our content combined with metadata, workflow, Information Management Policies and publishing of our Content Types.

My opinion is that you should always use Content Type Publishing in SharePoint 2010 to ensure consistency across Site Collections. There are numerous articles that explain on how to set up Content Type Publishing and I will go quickly through this in the next article.

Use metadata attached to Content Types within Office documents

You can use metadata attached to Content Types stored within SharePoint as fields within Word documents for example. So if we are writing a letter we can automatically insert the Author, Date and other metadata into the letter without having the user to type it in again.

This is very effective as it shows end users how useful metadata can be but also lessens that amount of work that they have to do. All of this should lead to greater user engagement.

One important thing to remember is that you can only attach a single template to a single Content Type. So you cannot have one Content Type called ‘Contract’ which has multiple Word templates associated with it. You will need to define a different Content Type for each template that you have (eg: Marketing Contract, HR Contract and so on).

Use Managed Metadata when possible

Managed Metadata should be used whenever possible for defining choice style metadata within SharePoint 2010. There are a number of restrictions to this of course but if you have the choice between using the old fashioned choice field and managed metadata you should be really use the new managed metadata construct.

From the great new user interface features such as Ajax type ahead functionality, to being easily able to create search refiners to metadata driven navigation features, Managed Metadata will be used extensively when we need choice style options for our Content Types.

Group related content into Document Sets

Document sets are very cool from a Records Management perspective because not only can you easily share metadata across all content in the set (which will aid in consistent metadata tagging) but you can also send entire Document Sets as records to a Records Centre.

Unfortunately Document Sets don’t play nice with the In-Place Records Management feature of SharePoint 2010 which may cause you not to use them. You can check out my blog for some more details on this.

So finally after all that we are ready to start the process of defining our Content Types for our fictitious EUSP Catering Co. See you all next time!

Note: Join Michal on September 25th when he'll be speaking at the first ever SharePoint Saturday Vancouver.

VIEW ALL ENTRIES IN THE SERIES

 

Comments

Kerri

Define Content Types for Records Management – Part 1

Michal, I find records management and IA really fascinating so I enjoy your articles a lot, thanks for contributing!

Posted 24-Sep-2010 by Kerri
Michal Pisarek

Define Content Types for Records Management – Part 1

Thanks for the kind words Kerri!

Posted 24-Sep-2010 by Michal Pisarek
Roger Skauen

Define Content Types for Records Management – Part 1

The challenges related to information management (RM&DM) is too often underestimated when companies rolls out new platforms like SharePoint, so I wish your article series about Content Types the best!

Thanks for contributing :)

Posted 25-Sep-2010 by Roger Skauen
Define Content Types for Records Management - Part 2 | EndUserSharePoint.com

Define Content Types for Records Management – Part 1

[...] the previous article I talked about a whole range of tips on how to define Content Types. In this article I am going to [...]

Posted 08-Oct-2010 by Define Content Types for Records Management - Part 2 | EndUserSharePoint.com

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: