SharePoint Retention Schedule Limitations

In SharePoint 2010 retention is limited to creating stages based off a date property on the SharePoint item. For example, an administrator can create an Information Management Policy that defines a retention schedule to Permanently Delete the item 7 years after it was declared a record. Here's a screen showing the SharePoint out-of-the-box retention builder form.

SharePoint Retention Form:

Blog2A
Blog2A

SharePoint Available Time Periods:

Blog2B
Blog2B

The above example is common, but lacks the ability to control the time period. What if you wanted the Time Period to be from calendar years, or from the company’s fiscal date?

Collabware CLM Retention Schedule Solutions

SharePoint out-of -the-box has other retention schedule limitations. Here are a few solutions that Collabware CLM has implemented to address these limitations:

1. Event-BasedRetention:  This allows definition of a retention schedule based on an unknown future occurrence date. Event-based retention is used to track records that rely on a future occasion to trigger their retention. This function can be useful for series of records that should be treated as a group, such as a project file. Event-based retention also gives the user the ability to determine when their records are no longer needed, while still capturing them under their appropriate classification and retention.

The Policy Stage:

Blog2C
Blog2C

The Lifecycle Details for a Record:

Blog2C
Blog2C

Notice that there is no scheduled occurrence date for this record. Once the record is added to an event instance, its occurrence date is then scheduled.

Add Record to an Event:

Blog2C
Blog2C

The Lifecycle Details for a Record:

Blog2C
Blog2C

2. Supersede or Obsolete Retention: This allows definition of a retention schedule based on an unknown future occurrence date dependent on another related record. Supersede or obsolete retention is another useful way of capturing records that rely on some future event to trigger their retention. In this case, the event is the superseding or obsolescence of the record. When the record no longer has any power to guide business, it is considered obsolete; when the record's power has been replaced by another record, it is considered superseded.

The Policy Stage:

Blog2C
Blog2C

The Lifecycle Details for a Record:

Blog2C
Blog2C

Notice that there is no scheduled occurrence date for this record. Once the record is declared obsolete or superseded, its occurrence date will be set.

Declare as Obsolete:

Blog2C
Blog2C

The Lifecycle Details for a Record:

Blog2C
Blog2C

This next example shows how another record (Procedure 1101A.docx) can supersede an existing record (Procedure 1101.docx).

The Lifecycle Details for a Superseding Record:

Blog2C
Blog2C

Supersede Other Record:

Blog2C
Blog2C

Find the Target Record:

Blog2C
Blog2C

Superseded Target Record:

Blog2C
Blog2C

3. Case-Closed Retention: Case-closed retention is similar to event-based retention, although it can be used in a much broader fashion. Records created by a variety of business groups, such as finance, engineering, planning and legal can all be captured under the same Case Category, and when the project is complete, retention can be triggered for all these records at the same time, through the act of closing the Case Category.

The Policy Stage:

Blog2C
Blog2C

The Lifecycle Details for a Record:

Blog2C
Blog2C

Set the Close Date of the ‘0660 - 2012 Bridge Project’ Record Category. This will set the occurrence date and the retention will be scheduled.

Edit Record Category:

Blog2C
Blog2C

The Lifecycle Details for a Record:

Blog2C
Blog2C

Collabware CLM offers an organization the tools to build retention schedules that align with what Record Managers are familiar with in the paper world. The above policy examples were also created and configured by an account representing a Record Manager; no IT involvement or SharePoint administrator was required. In my next blog post I hope to discuss how Collabware CLM handles the disposition of records.