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
SharePoint Available Time Periods:
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
The Lifecycle Details for a Record:
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
The Lifecycle Details for a Record:
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
The Lifecycle Details for a Record:
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
The Lifecycle Details for a Record:
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
Supersede Other Record:
Blog2C
Find the Target Record:
Blog2C
Superseded Target Record:
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
The Lifecycle Details for a Record:
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
The Lifecycle Details for a Record:
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.
Click here to visit the Collabware CLM page or download the brochure here:
