Friday, October 28, 2011

A look at Information Management Policies - In Place Records

Content Management is one of the most critical items that you can plan for when creating your SharePoint site. A site with a lot of outdated content negatively affects performance, storage, backup/restore, search results and usability. If you have a large site with lots of content, implementing a process that will automatically remove outdated content from your end-user’s view will make it easier for your users to find the most current content available and maintenance of that content much easier.

A current request I have is to be able to automatically "Archive" content on a Publishing site.  They do not want to have this "Archived" content displayed with the active content on their site in web parts or views, but user must be able to search for and review it.  They also don't want to lose the version history of their content and they want the process to be as automated as possible.  Long story short, we are recommending declaring "In-Place Records" for all content that should no longer be considered "Active".   All of our web parts and active views will filter out content based on if it is a record or not. 

In-Place Records in new to SharePoint 2010 and adds some nifty little features that are not available with just applying a "Status" field or setting the Scheduling End Date. The following information is the result of my research of using the out of the box scheduling vs. using Information Management Policy options available. The pros and cons listed are specific to our clients' preferences, therefore something that is listed as a con could be a pro for your organization, or vice versa.

Scheduling Start Date and Scheduling End Date

These out of the box fields allow you to determine when your end-users will be able to view content that you have published in a library on your site. You must have versioning, approval and publishing features turned on.

Scheduling Start Date: The options are to start Publishing Immediately or to set a date when the content should be published. When a page is approved for publication, but the publishing start date is in the future, the site sets the content’s status to “Scheduled”. When the start date arrives, the page status changes from “Scheduled” to “Approved”.

If you have do not have any published versions of the page, this is a great way to create content and publish it later. However, if you have a published version and set this field to a date after <Today>, the content will no longer be available to the end user until that date…in other words, you cannot schedule an update to existing content.

Scheduling End Date: On this date the content becomes a draft of the major publishing view with a version of published version number +.1. The content can no longer be viewed by readers.

The Pros:

  • Allows you to complete the content in advance and pre-schedule when users will be able to view it
  • Automatically removes the content from user’s view without further action from the publisher

The Cons:

  • Only available with Pages, Document Libraries and certain lists
  • End users (read access) will no longer have access to content past the “Scheduling End Date” (our client wants to be able to search for and review archived content)
  • If you change the “Scheduling Start Date” for a published version, users will no longer be able to view any version of the document until the “Scheduling Start Date”
    • This means that you can't schedule a "Change" if you want the current published data to be visible until the change is applicable.
  • To change a Publishing Start or Publishing End date, you must check out the content, make the update, publish and re-approve (if approval is turned on).
    • Changing a document property changes the status to “Draft” and creates a new minor version.

 Information Management Policies

An Information Management Policy is a fancy way of saying “a set of rules for content to determine how long it should live on your server and what should happen to it after a certain amount of time”.   Policies are applied to Content Types and can be applied at the parent site level, a child site level or at a list level.   Each Content Type can have its own set of policies.

It is a best practice to define retention policies as a part of a governance plan.  Retention policies should be defined in order to maintain a healthy server over a long period of time.   Additional reasons for Information Management policies include some government rules and regulations or legal reasons. 

A well-managed retention policy will allow you to determine what will happen to different content types based on rules that you can set up at the parent level and apply to the entire site collection. 

Retention

The “Enable Expiration” feature in 2007 has been upgraded to “Enable Retention” in 2010.  Many new features are included with the upgrade, such as allowing different stages of retention that you want to manage, allowing you to determine new actions and the ability to repeat the process until the next stage is reached.

You can set the start date based on any date field contained in the content type.  For example, it could be 1 year after the default “Created” date or 20 days after a manually created “Review” date.  Unless an administrator sets up a custom expiration formula on the server that you have access to, the formula for determining the date will always be <Date> + # <days, months or years>.    

The Retention Actions available are

  • Move to Recycle Bin - Moving an item to the recycle bin means that it will live there for 30 days until it is automatically deleted unless the recycle bin is manually emptied by an administrator.
  • Permanently Delete - Instantly removes it from the site collection.   The only way to recover is from a back up.
  • Transfer to another location - This is a great feature that will allow you to send this to another site or to a records center if you have one set up.
  • Start a workflow - my personal favorite feature.  This will allow you to start an out of the box workflow, such as disposition workflow or three-state workflow, or start a custom workflow that you have created.
  • Skip to next stage - With the new option of allowing stages in retention policies we can now set part of the policy to automatically move from one stage to the next without user intervention.
  • Declare a record - one of my favorite new features, the ability to declare a record in place.  I describe more about this feature below. 
  • Delete previous drafts - when you have versioning on you can get rid of the drafts (minor versions such as 1.3, 2.4, etc.)
  • Delete all previous versions - this will remove all minor AND major versions. 

You can schedule how often an item goes through its current retention stage, based on days, months or years.

More details about: Declare a record

In-place records management is a new feature that allows you to keep a document where it currently lives, but declare it a record.   In 2007, you had to move the document to a records site.   You must turn this feature on Site Settings before it is availalbe.  Some of the in-place records features include:

  • You can apply different retention policies based on if is a record or not
    • Permissions do not change
      • You must have at least “Contribute” access to declare a record and the administrator must set up the ability for contributors to declare a record.
      • Viewers will still be able to view content that is declared a record unless access to the document is changed.
    • Declaring an item as a record does not affect versions
    • Collaboration site administrators can manage Record Declaration Properties:
      • Record Restrictions: Specify if any edit or delete restrictions should be placed on a document once it is declared a record.

Ø No Additional Restrictions: Authorized users can still edit records.

Ø  Block Delete: Records can be edited by authorized users but not edited.

Ø  Block Edit and Delete:  Once content is marked as a record, it cannot be modified until a user “undeclares” it as a record.

§  All options in the ribbon and edit menus  for edit/delete are disabled 

  • Record Declaration Availability: Specify whether authorized users can overwrite the rules for this content type in a document library

Policies can be set up at a Site Collection level, a Site Level or a list level. The Site Administrator can control at which level policies are set up with this setting. 

  •    Declaration Roles: Who can declare or undeclared records

  • Manual record declaration can be configured on Site Collection level and overridden in each document library by authorized users, depending on the settings.

 

  • After the content is declared as a record, it can have policies and restrictions that differ from the same content type that is not a record. The policies are added to either the Content Types at the parent, or they can be added directly on the document libraries.

 

  • The page or document has the following notification on it for editors that have the ribbon showing.  It does not appear if the ribbon is hidden. 

 

  • Custom Workflows can be used to declare an item as a record
    • With this particular client, we will be using a workflow that allow a user to determine if the expiration can be extended for another year, or if the site should set the content as part of it's archive by declaring it a record.

 

  • There is a default “Declared Record” property set when an item is declared an in-place record.  It is a date/time field that records the date the item was declared a record. 

 

  • Views can be configured to exclude records or to only include them for an all-archived view.
    •  Filters can be based on “Declared Record” = Blank for active events

 

  • For the Active view, filter on Declared Record equal to [blank] (as in don't enter a value for the field). For the All Records view, set the filter on Declared Record not equal to [blank].

 

  • Declaring content as a “Record” does not change the page status.

 

  • The content is checked out to “System Account”

 

  • You can start a workflow on a “Record”, but the actions will be based on the Record Restrictions set by the Administrator

To Undeclare a record, go to compliance Details and click “Undeclare Record”

 NOTE:  If you declare a record multiple times, you will need to “undeclare it” the same number of times for it to no longer be listed as a record.  The timestamp will change each time you undeclare it if you declared it at different times.

When you undeclare a record, it removes the banner from the top and the date in the “Declared Record” property.

The Pros:

  • Automated way to archive content
  • Views are easy to create and change as needed
  • Different content types can follow different rules
  • Same content types can follow different rules based on if they are records or not
  • Site collection administrator can determine who can declare or undeclared records separately
  • Does not affect versioning
  • Any content can be turned into a record

The Cons:

  • All web parts and views must be filtered to exclude records
  • The yellow status bar text for a record isn’t the most user-friendly (but this seems to only appear when the ribbon is showing)

To complete your content management policies, you can set a "next" stage for each content type, such as to automatically move or delete content after X years.

You will need to determine the best content management policies for your organization's needs.  More complex policies may require some of the great third-party options out there, but Microsoft has done a great job of expanding the options available.