Before I went on holiday last week, I attended the SharePoint user group meeting that was happening in London. A couple of guys from Cap Gemini were doing a presentation on records management (RM) in SharePoint 2007. This will describe my impressions (my memory ain’t so good, so these are my notes…), and how it appears to work. I’ll start with my conclusions, and then move on to how the thing actually works.

Conclusion: Well, it has basic RM functionality, but the guy taking the presentation did comment that it doesn’t fulfil all the legal requirements for some of the countries in Europe. Nobody was entirely sure which ones, though, and I’m not sure about the UK. Because of the structure of the system, I did find myself wondering if you might not end up with absurdly large lists of documents (see below). It should be possible, to some degree, to plug into the RM facilities of the system, and the use of the workflow foundation on the expiry of the retention schedule is nice as it should provide a good degree of flexibility.

Okay, so how does it work? First, a little about the structure of SharePoint sites and lists. Then we’ll consider content types, and then policies and RM.

So SharePoint is made up of Site Collections, which are collections of, well, Sites. Sites contain Lists and, potentially, subsites. This is kind of a difficult concept coming from the Livelink world, and the analogies of folders or projects don’t really fit. It’s almost that sites provide the hierarchy, while lists are the folders, discussions, task lists, etc., that you get in Livelink. Sites can contain many lists of the same type. So, for example, you might have a structure like

• Organisation SharePoint 2007 system
  • Organisation Site Collection
    • Accounts Site
      • Travel Expenses List
      • Documents In List
      • Documents Out List
      • Discussion List
      • …
    • Invoice Site
      • Travel Expenses List
      • Invoice Forms List
      • …
    • Pensions Site
      • Travel Expenses List
      • Pensions Documents List
      • Complaint Documents List
      • Pensions Form List
      • Project Deathrattle Sub site
        • Project’s Documents List
        • Projects News List
      • …

(For some reason, Documents Lists and Forms Lists are actually called ‘Libraries’ in SharePoint terminology. I’m going to call them lists though).

Okay, next concept – content types. This is basically a definition of ‘columns’ of metadata that we want to capture. These definitions can then be applied to Lists throughout the site. For example, we might want to define a ‘Travel Expenses’ content type, which we could apply to the ‘Travel Expenses’ lists in each of the 3 sites in the example above. It could define metadata like, date of travel, cost, destination, etc., and we could make this mandatory. Thus, we define what we want to capture for multiple lists.

Content types are important as they control where a document ends up in the Record management system. We’ll see this in a bit.

Records Management adds a special ‘Records Repository’ site to the SharePoint system – I’m not clear if this is on a system or site collection level. This site is optimised for RM – options on menus, etc., are geared towards RM actions and stuff.

What we do is create an Information Management Policy (retention schedule) for either a content type, or a particular document list. For example, we could define a policy just for the Pension ‘Complaint Documents List’, or if we created a policy for our ‘Travel Expenses’ content type, then all 3 lists using it would have an information policy defined.

The information policy has features like Labels, auditing, Barcodes, expiration dates and rendition to other formats. We didn’t really go into these options. Expiration has a number of ‘standard’ options (like deleting the document), or you can create a Windows workflow to run when expiration occurs.

Having defined a source, we define a destination in the Records Repository (see here). This will be a list, with a content type specifying the metadata to capture. I don’t think that this HAS to be the same as the content type in the source list, though that would be a logical choice.

Defining the source and destination like that populates a ‘routing table’. A user can then select a function from a document’s menu to save a copy of the document as a record. It is worth noting, it IS a copy of the document. SharePoint looks up the document’s content type, and routes it (based upon the ‘routing table’) to the appropriate list. There are special lists for ‘unclassified’ documents (those without a routing), and for documents with incomplete mandatory metadata (these can be completed and put into the right lists)

So, for example, we might have a ‘Travel Expenses Records’ list, and have any document with a content type of ‘Travel Expenses’ that is declared as a record gets put in this list. Thus, travel expenses records from all 3 departments would end up in this list. ‘Complaint Documents’ might be routed to a different list.

So, we’ve got a bunch of documents in our lists, and they have retention schedules, which will eventually expire and delete/archive the documents. When we’re sued, though, we might want to ‘hold’ documents related to the case, so they don’t get deleted.

First, we create a hold (giving it a name, details, etc.), and then we add documents to it. Documents and holds have a many-to-many relationship – a hold can apply to many documents, and documents can be part of many holds. If a document has any holds applied, it can’t expire or be deleted. It is possible to perform a search, and then hold all documents returned by the search.

The other part of the demonstration looked at declaring a document as a record twice. This would create 2 records in the Records Repository, even if the document is unchanged – i.e.. EVEN IF THE TWO RECORDS ARE THE SAME. So, the second part of the demo looked at adding to the ‘routing stack’ – a series of things that happen when a document is declared a record. Basically, what this did was add a ‘filter’, which recorded which items had been stored as records, and rejected attempts to store an item that had been recorded already. See here for more details.