August 22, 2012

Archive: Out of the Box Content Management Options in SharePoint

This was originally written in August 2012.  It is being re-posted here for archival purposes


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

In order to get active content to no longer be visible to readers of your site, SharePoint 2010 offers the following options out of the box:

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 to 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 no 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 will no longer have access to content past the “Scheduling End Date”
  • 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”
  • To change a Publishing Start or Publishing End date, you must check out the content, make the update, publish and approve.

o   Changing a document property changes the status to “Draft” and creates a new minor version.

Disposition Workflow:

This is an out of the box workflow that will only allow a user to choose whether the system should delete a piece of content or not to delete it.

The workflow can be configured to start automatically when content expires or started manually by authorized users.    In order to set an expiration date for automatically starting the workflow, you must use the Information Management Policy Settings to tell the site when the page expires.   More information about these settings are below.

The workflow will create an administrative task for review.  Individual tasks are not assigned and cannot send a notification based on “Assigned To”.  These tasks are able to be modified in large groups at once.   The workflow also includes bulk task completion so that individuals can process large numbers of items for deletion in one step.


The options are to “Delete this item”, or “Do not delete this item”, which will leave the content in place.

In order to use this feature, it must be turned on by a site administrator.

The Pros:

  • Automated way to manage content
  • Content is permanently deleted from your site

The Cons:

  • No accountability – tasks are not assigned to any one person so it is a process that must be manually managed
  • No history – workflow tasks are deleted upon completion and no record of them exist
  • Content is immediately and permanently deleted from your site, along with the task and any comments a user may have entered when deleting the item – it does not go into any recycle bin.

o   Note:  If Auditing is enabled, this item would appear on the audit log

  • This workflow cannot be customized.
  • If you choose not to delete an item, the workflow will show that the item was run, but the task will be deleted, losing any comments.
  • This workflow does not show up in the “Site Workflows” view.

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.

Information Management polices include:


Auditing logs events and operations that affect list items.  You can configure which of the following items you want the system to audit:

  • Item Edits
  • Item Views
  • Items Checked In or Checked Out
  • Permissions changed on an item
  • Document deletion

Access to the audit log is tightly restricted. Only administrators (or users who are granted sufficient privileges) are able to view the audit history, using Microsoft Office Excel-based reports. And no user can selectively edit or delete individual audit entries.


The “Enable Expiration” feature in 2007 has been upgraded to “Enable Retention”.  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.

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 set up.

You can set the start date based on any date field contained in the content type.  For example, it could be 365 days 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
  • Permanently Delete
  • Transfer to another location
  • Start a workflow
  • Skip to next stage
  • Declare a record
  • Delete previous drafts
  • Delete all previous versions

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

Some Noteworthy Retention Actions:

Start a Workflow (This can be used to start off an out of the box or custom workflow)

You can tell the site to start an out of the box workflow, or a custom workflow that is designed to do what you want it to do, including but not limited to:

  • Route the document to content owner to determine what should happen to the content when it reaches a certain date
  • Automatically change the item’s metadata

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.   Some of the in-place records feature include:

o   You can apply different retention policies based on if is a record or not

o   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.

o   Declaring an item as a record does not affect versions

o   Collaboration site administrators can manage Record Declaration Properties:

Record Restrictions:


– No Additional settings: 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:


  • Declaration Roles: Who can declare or undeclared records


o   Manual record declaration can be configured on Site Collection level and overridden in each document library by authorized users.

o   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.

o   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.

o   Custom Workflows can be used to declare an item as a record

o   “Declared Record” property = Date/time the item was declared a record.

o   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].

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

o   The content is checked out to “System Account”


o   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

Search Scopes still need to be determined.  However, if we cannot create a search scope on these properties, we can still include a “Status” field for search scopes

You will need to turn on In-Place Record Management feature in Site Collection Administrators to use this function.

To complete the list Information Management Policy feature, also available when setting up a policy:


This feature will automatically allow you to create barcodes for each piece of content.   This is most commonly used when for printing and attaching to an item for storage.


Labels can be applied when a document is printed.  Labels can include metadata about the content, with the exception of any calculated fields or built-in field, such as “CreatedBy”.

Add Comment

Your email address will not be published.