In one of our current SharePoint ECM projects, we’re helping the client implement the Operational Records Classification Systems (ORCS) and Administrative Records Classification System (ARCS) information schedule with Collabware CLM

The ORCS and ARCS information schedule is the file plan for the for BC Provincial Government, and it is often adopted by broader public sector organizations and crown corporations within the province of BC.

The goals of the ORCS and ARCS information schedule are to

• Ensure records are kept for as long as required;

• Identify records of enduring value for preservation; and

• Ensure that others are routinely destroyed when they are no longer needed.

As we were implementing the file plan for our client, we noticed some of the retention schedules were not necessarily optimal for the organization to effectively apply the retention schedules while at the same time minimizing the burden on end users.  

Of particular note is use of SO  that the ARCS and ORCS User Guide defines as “Explains when a file designated SO should be closed.” In most file plans SO stands for supersede or obsolete – meaning that the file retention is calculated based on the content having been replaced by a newer version (to supersede) or simply when they are no longer relevant (have been made obsolete).

For example, if a corporate policy for overtime has been updated, then the previous version of that policy has been now superseded and may, for example, need to be kept for seven more years before running through a destruction process. You’ll want to keep it as if you’re being sued by a former employee for overtime from two years ago – you’ll want to know what the official overtime policy was back in 2017.

Looking at ORCS and ARCS, many of the record categories have a retention schedule driven by SO. For example, many of the record categories that fall under “6820 - Information Systems Operations” implement a SO type retention schedule as seen below:

Each area of the records categories in the ORCS and ARCS file plan that leverages SO will define what SO means. For example for “6450-80 - IT application/system documentation - final versions”,  defines SO as

upon completion of the post-implementation review, or when the project is abandoned, and when no longer required for reference.

Fair enough – it’s telling us that we can get rid of the documentation when it’s no longer useful.

The problem here is that SO typically implies that the end user needs to step in and take action – essentially telling the system that a given document is no longer useful. Not too onerous for say policies where you may only have 100 policies organization-wide, but the ORCS and ARCS file plan has lots of record categories that define a SO type set up that apply to millions of documents. 

Now we could have implemented the file plan as-is, but then we’re expecting our client to go in and manually flag perhaps millions of documents over time. This is certainly not the most efficient means of getting documents to run through a disposition process.

Instead, we decided to help automate this process – we worked with the client to determine for a given record category – what was the longest period of time that they felt the content would be relevant.

For example, 6820-06 Log files which include application, server, web site, system, audit, event, and equivalent logs define SO to mean  “when no longer required”. The Organization determined that the IT-related log files would not typically be required after two or three years.

Instead of requiring that end users go back into all the log files and flag them as SO we automatically kick off a disposition approval process on log files after three years whereby the end user can opt to save the log files for an additional, say two years, or can run them through a disposition workflow.

One of my favorite things about Collabware CLM is the flexibility of the retention workflows. They allow multiple paths through the workflow. In this case we can allow end users to flag documents as SO (as unlikely as that is) but also automatically kick off a disposition approval process after a reasonable amount of time.

It seems, from our vantage point so far, that this is a good compromise that helps automate the compliance process, minimizes the burden of the end user while staying within the spirit and intent of the ORCS and ARCS file plan.

Below is a screenshot of an example retention workflow that:

• Waits for one year after the last modified date (to provide an adequate collaboration window)

• Deletes the version history of the document to protect our clients from producing 100’s of versions for an ATIP or FOI request. (this is actually a custom Gravity Union Collabware workflow action)

• Declares the item to be a record

• Waits for the item to be flagged as superseded or obsolete OR automatically pushes forward after 10 years and then depending on the path out will run through a given approval process before being destroyed by Collabware CLM.

After some quick calculations we figured that we will have helped automate the destruction of over 2.5 million documents over the next 7 years saving over three thousand of hours of effort for the organization!