shutterstock_137747807.jpg

Where does Records Management fit in in Office 365?

Old news: SharePoint 2010 Records Management doesn’t perform well in the e-discovery space. For some (most!) organizations, this isn’t a detriment.

Most likely, IT pulls whatever objects are necessary to meet counsels’ expectations according to its own standard operating procedure (SOP), which usually includes a third party software. Information Technology has performed e-discovery far longer and more regularly than Records Management has been allowed to implement electronic retention.

Editor's Note: This article has been revised to clarify points made in the previous version

Automation is Beautiful

But SharePoint 2010 Records Management services do automate records declaration beautifully. I was overjoyed the first time I architected them successfully. Of course, I mapped the records retention schedule against SharePoint 2010 RM.

Then I leveraged the records series content types holistically across site collections, attached information policies, and recalculated the indexing services to run at certain intervals. I can’t tell you how excited I was when that first object moved to the matching folder the first time. I’m pretty sure I sound[ed] my barbaric yawp across the roofs of the world.

Hazards Ahead

Corporate records programs have learned to trust off-the-shelf SharePoint 2010 Records Management services. It is an inexpensive automated records declaration option in an era when Records programs are squeezed drastically -- or suspended entirely.

I realized my Records program might be vulnerable when I discovered that Office 365 doesn’t have a corresponding Records Center template (pre-upgrade). This revelation is more than problematic: the lack of automation can be catastrophic to a Records program’s reputation. If you leverage automated records declaration in SharePoint also, yours may be in trouble as well.

The Choices Are ...

It is the textbook dilemma of the needs of the information architecture superseding records policy. The design choice has potentially long-term, negative connotations for us information professionals. If the company has automated records declaration via SharePoint 2010 and the Information Technology department wishes to embrace cloud services, Records has a difficult choice: do nothing, deconstruct and implement manual records declaration, or call in third party experts to devise something new.

“Do nothing” is not the best option in this particular instance. Number one, something will eventually break. Number two, Records is a forward-thinking department; it cannot be seen as restricted to one solution because a lack of options exist. Number three, employee turnover is so high that the future administrator will lose all context of architecture. Number four, retention schedules will change and unraveling the Records Center to reconstruct according to the new schedule is a tremendous headache.

Manual records retention is a kind of option, but it’s an inferior one:

  • In-Place RM still exists in Office 365; however, it’s a status symbol only. A one or a zero -- the record exists or it doesn’t. In other words, the Records Administrator does not have the option to manage it from the back end. The good news: Records interacts with end users. The bad news: unless the C-level insists and communicates the necessity of it, end users never have time for the annual records review. Destruction doesn’t happen.
  • The best way to architect out-of-the-box manual Records Management services in Office 365 is to create a Records subsite per site collection. By all means, use the same folders as you planned for the SharePoint 2010 Records Center. You may choose to bypass content types entirely; you may use the same information policies directly behind each folder.

    Copy those objects from the main site collection pages that should be declared as records to the Records subsite’s appropriate folder. Since it’s a copy (move is unavailable), note the metadata changes and the peer must return to the original object to delete it. It’s incredibly cumbersome. Meanwhile, you must be an administrator per site collection; how likely is it that a Director will approve? Unless the C-level insists and communicates the necessity of it, end users will object.

You can always call in a third party to initiate a solution. Information Technology will. On the one hand, you’re demonstrating that you seek a compromise. Records cannot be the impediment to migrating to the cloud. On the other, you want to leverage your good partnership with IT very carefully at this juncture. Records is your project. What you absolutely do not want: Records reduced to the back seat, assigned with cleaning up legacy data. A noble effort, but not the strategic information governance opportunity we currently seek.

On the Plus Side

The positive to managing records in Office 365: editing retention periods is easier. Your information maps have never been more important. As you sit down with each peer to plan their folder structures, edit the maps. Explain why and how each site collection’s records folders are a part of a larger process-based schedule. Unravel site permissions in order to rebuild them. You have the opportunity to express the mission and importance of the Records program once more. As your Information Technology department prepares for 2014’s projects, seize the moment for Records Management in Office 365.

Title image courtesy of rosedesigns (Shutterstock)

Editor's Note: This isn't the first time that Mimi talks records management in SharePoint (and it won't be the last). Read more in Say it Ain't So, Joe: You Can't Do Records Management in SharePoint