Editor's Note: Today Microsoft kicks off the SharePoint Conference for 2011. To coincide with this, the MVP Award Program blog will post an article by SharePoint MVP Becky Bertram. On Monday 10/10, we will continue with our Developer series.
If you’re like me, you have a bookcase somewhere in your office where you keep books and documents that you want easy access to because you might want to reference that information at some later date. My bookcase has a shelf where I keep things such as training manuals, design specifications for past projects, industry publications, as well as books by my favorite authors. Unfortunately, after several years of collecting these sorts of materials, I find that the information I’m keeping is pretty outdated. I have to start asking myself if I really need to keep that book about SharePoint 2003 or if that MSDN Magazine from 2006 is really going to be helpful anymore. There comes a point in time where I have to clean out the old so I have room for the new. If I don’t do some house cleaning, I’ll have so much outdated material on my shelf that I’ll no longer easily be able reach for my more recent documents or books without having to sift through a decade or more of old papers.
The same logic holds true for document retention in an electronic document repository like SharePoint. Old documents stored in a SharePoint environment take up server space just as my documents take up my shelf space. Reducing the amount of content you keep in your SharePoint environment reduces the cost associated with maintaining large content databases (or file systems, if you’re using Remote Blob Storage). Furthermore, there more documents that are stored in a site, the more important it becomes to adequately organize content (whether that means placing documents in locations where they can be easily found by users, or using well-thought out metadata tags) so that users can sort through the volume of documents to find just the documents they want. By removing outdated material from your site, you’re reducing the amount of time it takes end users to sort through their search results or browse through document libraries to find what they’re looking for. Finally, there are sometimes legal requirements to eradicate documents from a system after a given amount of time. To sum up, removing old and unnecessary content from your SharePoint environment can: reduce the cost associated with server space, reduce the human cost of wasted time sorting through piles of documents to find the right one, and fulfill legal requirements.
According to MSDN, “An information management policy is a set of rules that govern the availability and behavior of a certain type of important content.” Retention rules are considered a kind of information management policy. (Note: information management policies are only available for the SharePoint 2010 server product, and are not available in SharePoint Foundation 2010.) You can create retention policies in several ways:
- You can create a retention policy definition within your site collection, then apply that policy to content types throughout the site.
- You can create a retention policy that’s associated with a content type that’s defined in the root of the site collection.
- You can create a retention policy that’s associated with a local content type that has been applied to a list or library.
- You can create a retention policy directly on a list or library itself.
Some site templates come pre-configured to allow you to apply information management policies. If you don’t have the ability to apply information management policies in your site collection, you can activate the “Library and Folder Based Retention” site collection feature to make it possible. If you activate the “In Place Records Management” feature in your site collection, you’ll also have the ability to apply separate retention policies for records and for non-records.
When creating a retention policy, you have the ability to create multiple “stages”. It’s possible to connect these stages so that multiple actions happen within a single retention policy. Furthermore, when creating retention policies on content types that have Date and Time columns, it’s possible to incorporate that property into the retention policy. For example, say you have a content type called “Employee Handbook”, which has a column called “Last Review Date” that’s of type Date and Time. When the document is first created, the value of Last Review Date gets set to the current date. You could then create a first stage in your retention policy that kicks off a workflow one year from the last modified date of the document. That workflow sends an e-mail to the person who created the document, asking them to update the Last Review Date column. You could then have a second stage in your retention policy that gets fired 2 years from the Last Review Date, which sends the item to the Recycle Bin. If the reviewer decides they want to keep the document around, they can modify the Last Review Date column and thereby put off the recycling of the document. Otherwise, the document will be eventually recycled.
Additionally, it’s possible to create recurring steps in a retention policy. Your retention policy might simply send an e-mail to the owner of the document every year for them to review. If they decide the document is outdated, it can be left up to them to recycle the document manually. In that case, the recurring retention policy simply brings the document to someone’s attention to review for relevance.
Let’s walk through an example of creating a retention policy at the site collection, then applying that retention policy to a content type we use in a library.
First, go to the Site Settings page in the top level site of your site collection. Under the “Site Collection Administration” heading, click on the link that says “Site Collection Features” and ensure that the “Library and Folder Based Retention” feature has been activated. Next, return to the Site Settings page in the top level site of your site collection and click on the “Site collection policies” link, (also under the “Site Collection Administration” heading). On the Policies page, click the “Create” button in the toolbar. This takes you to a page where you can create a single information policy that could potentially include multiple types of policies (including auditing, barcode, and labeling policies, along with retention.) Give your policy a name of Created Plus One Year. For the sake of this example, we’re going to create a one stage retention policy. Next to the Retention heading on this page, click the checkbox next to the words “Enable Retention”. Click the link that says “Add a retention stage…”. This will pop open a window that looks like this:
You have various options for configuring your retention policy. The first thing you need to decide is what your triggering action is going to be; does your retention policy kick in when your document is first created, or when the document is modified? (If you have records enabled, the policy can kick in once the document is declared a record. If your document has a column of type Date and Time, that column value could be the triggering date.) Next, you need to determine how long the retention policy is for. You can enter a numerical value, with your unit of time being days, months, or years. The final decision you need to make is what to do once the specified period of time has elapsed. (Not all of the triggered actions can be applied to retention policies created at the site collection. You’ll be notified if an action is not available.)
List of Available Triggered Actions
|
Move to Recycle Bin |
Items that are placed in the recycle bin are not deleted right away, but will stay in the recycle bin for a period of time (determined by your SharePoint administrator). By selecting Move to Recycle Bin, you’re assuming a document needs to be removed from the site when a period of time elapses, but you’re leaving a “back door” option available, in case you need to recover a document from the recycle bin that shouldn’t have been recycled. |
|
Permanently Delete |
This is final. Deleting a document means it is no longer in the system anymore, period. |
|
Transfer to another location |
This is an appropriate option if you’re using a separate library that serves as an archive location. When the retention period elapses, the document can be moved from its “active” location to its archive location. |
|
Start a workflow |
This allows you to choose to execute a workflow that has already been created, such as an approval workflow. |
|
Skip to next stage |
If your next stage executes an activity immediately, using the Skip to Next Stage option means you’re essentially making this stage a timer to set off the next activity. |
|
Declare record |
If you have enabled the use of records in your site collection, this option allows you to turn a non-record into a record when the specified period of time elapses. Since, in many cases, records cannot be altered, this is a way of allowing a document to remain in the system but become static and/or archived in place. |
|
Delete previous drafts |
This will leave the major versions of the document intact, but will remove all draft versions of the document. |
|
Delete all previous versions
|
Since each version of a document takes up valuable storage space, deleting past versions of a document after an elapsed amount of time can ensure the current version of the document is available for use, but unnecessary previous versions are purged. |
For the sake of this example, specify that one year after the document’s Created date, it should be moved to the recycle bin. Your new policy should look like this:
Now that you have your policy, it’s time to apply it. Create a new document library in your site. Go to the Library Settings page and click on the Information Management Policy Settings under the Permissions and Management heading. You’ll see a list of the content types that are being used in your library. Click on one of the content types. You’ll be taken to a page where you can choose three options: to have no retention, to define a new retention policy for that content type in that library, or to use an existing retention policy that’s been defined at the site collection level.
Choose the radio button that says “Use a site collection policy:” and select the policy you created previously, “Created Plus One Year”, then click the OK button.
Now that you have a new retention policy in place, go back to your library and add a new document to it using the content type to which you just added the retention policy. When looking at the context menu for the document, select the Compliance Details option.
This will pop open a window that will show you, among other things, the retention policy being applied to this document, like this:
This window will show you the date when the retention action will take place.
When a workflow is applied to a document in a library, it’s very hard to change the properties of that workflow once the workflow has been initiated. Unlike workflows, when a retention policy is changed, all the documents using that retention policy will immediately reflect that change.
Hopefully this article has given you an overview of the steps needed to create a new retention policy.
Here are some starting places to learn more about Information Management Policies in SharePoint 2010:
- Office.com: Create and apply information management policies
- TechNet: Information management policy planning (SharePoint Server 2010)
- MSDN: Managing Information Management Policy in SharePoint Server 2010 (ECM)
- ECM Training on MSDN: Lesson 13 - Retention and Holds
Author Bio
Becky Bertram is an independent SharePoint consultant living in the St. Louis area. She has been building web content management solutions for clients since 1999 using Microsoft technologies. Becky recently authored several chapters in the book SharePoint 2010 Six-in-One including several chapters on SharePoint development.
You can read Becky’s blog at http://blog.beckybertram.com, her RSS feed at http://feeds2.feedburner.com/BeckyBertramsBlog, or follow her on Twitter at http://twitter.com/beckybertram.