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

Archive: Manage Content Owners with the Content Query Web Part (CQWP)

This article was originally written in February 2012.  It is being reposted here as an archive.


The CQWP is my absolute favorite out of the box web part.  There are so many things that you can do with it.  There are lots of great blogs out there describing how you can present information to your end user with the CQWP, but did you know that you can also use it to determine how your content owners are using their sites?  Are they entering the type of data that you expected them to when you created your form?  Do content owners understand the importance of certain processes, such as clicking on “Publish” to make a page visible to readers?  Did your users really “get” the training that you gave them?

The current project I am working on is getting ready for a huge launch.  It is a publishing site with minor and major versioning turned on for Pages and Document Libraries.  It is one parent site with 100+ sub-sites, each containing hundreds of pages and documents.  We created a custom web part for content owners to link to other pages in the site collection.  This web part is really cool in that it shows the name of the page or document, the date it was reviewed, user ratings, a brief summary of the content and a link to the page or document.  We want to give the reader some useful information about the link before they decide to click on it.

With so much content in the site, we are relying on content owners to enter information about the content in a field that will be displayed in FAST Search and will also be displayed in the custom web part to link to related content.  The web part respects security, meaning a user must have access to the content in order to view the description in the web part.  With a big launch coming up, I wanted to do a content check to see how we are doing.  I don’t have time to go randomly clicking around on all these sites, so I created a couple of CQWP’s in order to see how the site is being populated.  They also ended up helping our development team complete a final review of our work.

If you’re new the CQWP, it is a web part that you can add to a web part page that can ask all of the sites in your site collection to give you a certain kind of information.

For example, if this wall of candy dispensers is your site collection, with each dispenser being one site:



Then this is the CQWP:


It has done all the work for you and grabbed multiple types of candies for you to consume quickly.  Yes, I could go to each tube and grab a little from each…but that just takes way too long and I want my candy NOW J.  With the CQWP you can filter your candy to get the specific ones that you need (if you don’t want the brown ones you don’t have to have them).

The CQWP is out of the box when the publishing feature is turned on, and it’s pretty quick to configure, especially with practice.  Here are some examples of how I was able to spend a few minutes looking at how the users are using the site and avoid deployment issues.  All of these queries were done in a browser, with no .xslt edits.  Each took no more than 15 minutes to configure, check, adjust, check, etc. to show exactly what I want on the page.

  • Check on published versions

o   Created 2 queries, one for all “Pages” libraries and one for all “Document Libraries” across the site collection, filtered by version is less than 1.0 and displays the last person that modified the content.

o   Problem Avoided:  Users not being able to access pages with page not found error, access denied errors and empty custom web parts

  • In order for a site reader to see a page or document the user must publish a page, or check in a major version.
  • This makes the version 1.0 (or 2.0, 3.0, etc. as you publish major versions…drafts always have a decimal).  A document that does not have a published version will have a version less than 1.0, which is why I filtered for by version.
  • There were over 400 pages and documents that did not have a published version just two weeks before go live


  • View user-completed fields

o   Created 2 queries, one for all “Pages” libraries and one for all “Document Libraries” across the site collection, which display the page title and our custom summary field and the content owner.

o   Problem Avoided:  Poor search results, poor cross-site link descriptions

  • There were over 300 items with “-“, an incomplete description or a duplicate description in the summary field that is displayed in our custom web part and search results.
  • Validation or unique values were not viable options in this case.


  • Discover users storing documents in wrong locations

o   Created one query for all sites, grouped by Page Layout, which showed users were putting Word and .pdf documents in their Pages Libraries (since they had no page layout)

o   Problem avoided:  Documents stored in wrong locations would not display correctly to the end user

  • We created Pages Libraries for publishing pages and Document Libraries for all stand-alone documents.  All documents are presented with a custom page that displays certain properties, taxonomy, user comments and ratings.

The overall outcome of these CQWP’s is that we were able to target the users that needed additional training tips in order to make sure their content is not only visible, but findable for end users on launch day.

Additionally, CQWP’s helped our development team to create a better product:

  • Monitor page layout usage and react

o   This was a unique project where editors were adding content while we were developing the site.  By creating CQWP’s that grouped all Pages by Page Layout we were able to:

  • View how users are actually using the page layouts we designed with content and adjust as needed
  • Allow our front end developer to make changes to design based on usage
  • Allow our back-end developers easy access to test the pages and how they worked with our custom controls and actual content

If you’re not familiar with the content query web part, I strongly recommend spending some time getting to know this very powerful web part.  It has been the fastest way for me to get feedback on what’s going on in our sites, so that we can address training issues, user adoption and design before they become a problem.