Records Management Feature -- Declaring Records in SharePoint Sites

Finally! After much patience on the part of this community, we can now talk about the next big area of our records management capabilities in the 2007 release – record declaration, classification, and the “Records Center” site.

But before moving forward, it’s worth spending a few minutes recapping what we’ve talked about so far, and how it fits into the “big picture” that we introduced in some of our earliest posts.

A quick recap

In our posts about “RM in the Information Age”, we proposed a framework that categorized DM/RM systems into “collaborative spaces” and “records spaces” as being appropriate for many organizations.

The first set of features we introduced, Content Types and the Document Information Panel, are especially relevant when dealing with “collaborative spaces” –they help ensure that employees will be classifying content and filling in appropriate metadata for it from the earliest stages of its lifecycle – even before that information becomes a record.

Information Management Policies also play a significant role in collaboration spaces, since they give records managers and compliance officers a way to introduce appropriate policies and controls into active content without adding additional burden on employees – such as expiring unimportant content to reduce unnecessary retention and auditing user activities on content where appropriate. (Of course, these capabilities are also vital for enforcing disposition schedules in a records space, but more on that in the next few posts.)

Now that we’ve laid out that toolkit for records managers trying to cope with collaborative spaces, let’s talk about what happens when content in those spaces reach a point where it needs to be declared as a record.

When does content become a record?

Before discussing any technology, the first question for record declaration is “when does content become a record”? For some organizations and types of information, content must be considered a record from the moment of its creation. (Think of a bill of materials created for a customer delivery, for example.)

However many types of information should not be considered records until they reach a certain lifecycle stage. For example, think of a professional services firm publishing a research report: early drafts of the reports may not need to be retained as records, but the final version delivered to its client is “evidence of a business transaction” and must be preserved accordingly.

Ensuring that records falling into the latter category are retained and declared is especially challenging – given that the employees who are collaborating on that content and performing the business transactions aren’t always highly motivated to actively retain those records.

Fortunately, the 2007 release of the Office system provides the ability to reduce the employee burden on record declaration and classification to a minimum. Content types provide the way for content to be classified, and workflows provide the way to automate business processes like content publishing and finalization… now let’s talk about SharePoint’s record declaration features.

Connecting collaborative sites to a “Records Center”

A key component of our original framework for “collaboration” and “records” spaces is a mechanism by which records can flow from collaboration spaces to a records space.

To address this need, we’ve defined an “open” set of interfaces for how collaborative sites can communicate with records sites, and enabled all of our products in the Office 2007 system to use those interfaces. (For the more technology inclined: the interfaces are defined using Web Services and e-mail protocols. And when we say “open” we mean that any Records Management application, not only the 2007 release of Office SharePoint Server, can be enabled to work with the declaration capabilities discussed below.)

So, a Windows SharePoint Services collaboration site can be connected to a Records Center site for use as its “records space”. (And when we start talking about e-mail records management, we’ll see that Exchange 2007 can also use a Records Center site for that purpose.)

The key concept of this interface, which you’ll learn more about in our next posting where we explore the inner working of a Records Center site, is that it provides a very simple way for collaborative spaces to interface with records spaces, without the collaborative space needing to know the inner workings (or complete file plan) of the records space. This is the main reason why record declaration from Windows SharePoint Services or Office SharePoint Server 2007 is a minimal end-user burden.

What happens when a record is declared from a SharePoint site?

Now that we’ve talked through the concepts, let’s look at what it means for a record to be declared from a SharePoint site.

Record declaration in SharePoint can be part of an automated process (for example, a workflow) or a manually initiated process via a “Send To” command (see image below).

Caption: Menu for a document in a SharePoint team site, showing the “Send to” command for the Records Center. (Note: The name displayed for the Records Center is customizable. The term “Northwind Records Center” is just an example.)

Whether it occurs as part of an automated process or manually, when a record is declared, the latest version of the record, all of its metadata, its audit history, and its content type information are sent to the Records Center site to which the SharePoint site is connected. The user doesn’t need to specify which Records Center site to use, nor do they need to specify a record series at declaration time – this information is inferred from the content type by the Records Center. (We’ll explore exactly how this inference is made in our next post.)

Once the Records Center has determined the appropriate record series, it will either accept the submission as is or, if additional metadata is required for the record in the Records Center beyond what was provided while the record was “active,” it can prompt the user to provide that information.

But in either case, the burden on the user is minimal. In fact, if the record is declared automatically via a workflow and no additional metadata for the record is required, then no end-user interaction is needed at all.

What happens to content in a SharePoint site after it is declared as a record?

The last question to address in this post is what happens after active content in a SharePoint site is declared as a record. For physical records, once a record is declared (i.e. sent to a records storage location) then the original owners of the record no longer have easy access to it –the physical object is out of their hands.

However, with digital records that need not be the case: once the active content has been declared as a record, an “official” record copy can be retained in the Records Center site, but content owners can still have a reference/working copy in their collaborative spaces (and thus have the same level of access to the content even after it has been declared for an appropriate period of time).

This is the approach we’ve enabled in SharePoint 2007. When a record is declared (and a copy sent to the Records Center site), we leave a working copy of the record in the SharePoint collaboration site, which can be expired appropriately using expiration policies. Workflows or other automated solutions can certainly choose not to leave a working copy in the original location, but by default the working copy is left in place – to minimize the end-user disruption of working with content that has been declared.

Hopefully this post starts to answer some of the big questions that we haven’t addressed thus far though it probably raises other questions. In our next post, we’ll explore in more depth the “Records Center” site provided by Office SharePoint Server 2007, including how it stores records declared from collaborative spaces like SharePoint sites and Exchange 2007 e-mail servers.

Thanks for reading!

- Ethan Gur-esh, Program Manager.