Retention and Expiration Changes and Execution Logic - ECM

Retention and Expiration Changes and Execution Logic - ECM

SharePoint 2010

Last modified: April 02, 2010

Applies to: SharePoint Server 2010

Microsoft SharePoint Server 2010 includes upgrades to scheduling and retention functionality. Specifically, the expiration framework is updated to support policies with more than one stage in their life cycle. To set up and manage scheduling and retention functionality, access a dashboard that shows all of the stages in a content type or the retention schedule of a location. You can also set up single-stage retention and expiration policies.

In addition to scheduling where content lives and how it is disposed of, a retention schedule can include specific instructions for safekeeping records, especially "vital" records. Vital records include items considered so important to the continued business operations of the enterprise that they should be reviewed periodically (usually annually). The periodic review requirement is built into the way retention schedules work.

Additionally, you can structure retention schedules to work with hierarchical storage management approaches to records management. For example, you can specify a hierarchy of storage that divides content into three categories: active and very important, less frequently used and less important, and infrequently used. To identify records by using this hierarchical storage system, you can use SharePoint metadata fields such as "Date Modified". You can also create custom metadata fields, such as "Date the contract was signed", to define metadata that you can use to manage content following the rules of your hierarchy. Hierarchical storage management that uses metadata works well because the retention scheduler bases actions on metadata.

To navigate to the information management policy UI for a content type, define a policy for it. You can enable a retention schedule policy and define a single stage or multiple stages. If you apply the policy to a list or to a folder, the UI that shows multistage schedules for content types also appears.

You can get data about the expiration policy that is being applied to an individual item. Because SharePoint Server 2010 supports multiple stages, the date column represents the "date of next action", which indicates the date when the expiration framework will run an expiration action on the item.The following fields provide information about an item's relationship to policy:

  • The Exempt From Policy field indicates whether the item is exempt from policy.

  • Original Expiration Date displays the value of the Expiration Date column, if the item is exempt from policy. Items are not expired when exempt from policy, regardless of the value of the Original Expiration Date field.

  • The Current Stage Number indicates the stage that currently is being evaluated on the item. Until the next stage occurs, the expiration framework moves an item to the next stage.

When considering multistage policy scenarios, it is useful to understand the logic by which policy and retention actions are executed. These rules affect how records are retained and when they expire.

By default, timer jobs are set to run weekly. Any stages that are due are processed at the time of expiration of the Expiration Policy timer job. However, if the policy schedule was just updated and the Information Management Policy timer job was not run to update the items, then they will not be processed by the Expiration policy timer job. To prevent this from happening, SharePoint Server 2010 runs the Information Policy timer job before the Expiration policy timer job by default.

Stage recurrence allows for a stage to be specified to repeat itself until any following stages are due. You can add, modify, or delete stages at the beginning, middle, or end of a schedule. When you do one of those things, the system may have executed some of the stages in the schedule already. The stage that is executed next for an item is always the stage after an item's last completed stage. For example, if an administrator adds a stage called New Stage after a stage called Pre-Existing Stage and before a stage called After Existing Stage, any items that completed Pre-Existing Stage and are waiting for After Existing Stage to occur now wait for New Stage instead.

© 2016 Microsoft