What records managers need to know about Sharepoint 2010

The following is a revised version of an article that appeared in the July 2011 edition of Informaa Quarterly, IQ, the quarterly journal of the Records and Information Management Professionals Australasia (RIMPA).

Sharepoint 2010, is starting to be used by more and more organisations. And it is being used to create and manage records.

The following are the things that records managers need to know about this product.

Check the version

First, Sharepoint 2010 is not Sharepoint 2007. Sharepoint 2010 has recordkeeping functionality built in that its predecessor lacked.

If someone is talking about a Sharepoint implementation, records managers need to know which version – 2007 or 2010.

Know what it does – and doesn’t. 

Microsoft has spent a lot of effort building recordkeeping functionality into Sharepoint 2010.

Records managers need to understand this functionality and how it works, and why they need to be part of the Sharepoint 2010 implementation process at the beginning of the project. They need to know and understand what it can do, and what it can’t.

For example, it doesn’t manage physical records out of the box. It doesn’t integrate well with Outlook. And it doesn’t do security classifications.*

It is very easy overlook or ignore the recordkeeping functionality in Sharepoint 2010 when it is being implemented. The product looks and behaves very much like Sharepoint 2007. So much so, it would be (and probably has been) easy for IT to implement it without any reference at all to records managers.

The first time records managers might find out about Sharepoint is when they find the intranet has been built using it and they are given a team site used to manage records.

The bits that matter

The following is a quick summary of the key recordkeeping elements Sharepoint 2010.


Sites and team sites in Sharepoint are more or less the same concept as a web site, grouped within an overall Site Collection.

Just like a web site, Sharepoint 2010 sites and team sites are locations accessed via an URL. But, unless access to the site or team site is open to everyone (such as the organisation’s intranet), access will be controlled (often by a site administrator) through a series of permissions. Records managers need to know and understand what this means for the management of records.

Sites may be made up of a range of different content types (see below) used by end users for all sorts of records and ‘non-records’.

One of the main reasons given by IT not to involve records managers in a Sharepoint 2010 implementation is likely to be that ‘there are no records stored on the sites’. This is a bit like saying that there are no records stored in network shares or in Outlook folders.

Of course, it depends on what industry sector you work in and the litigation risks associated with that sector and/or the records created by the organisation.

Without good planning and the involvement of records managers, users may create records on sites without any recordkeeping functionality at all.

Records managers may not know anything about these sites until well after they have been created and content added. By this time, the cat is out of the bag and it could be quite difficult (but not impossible) to retrofit the recordkeeping functionality that could have been applied at the beginning.

Lesson for records managers: Learn about the recordkeeping functionality of Sharepoint 2010 and get involved early with any implementation project.

Managed Metadata

Good metadata should be second nature to records managers. We know that metadata is a good way to describe records that will allow the organisation to find and make better use of records, including disposition decisions.

Sharepoint 2010 is a dream product for metadata lovers. The opportunities to apply metadata to – and in – records are almost limitless.

The close integration between Sharepoint 2010 and Office 2010 allows recordkeeping metadata to be be embedded in documents and then re-used on sites in metadata columns.

A key feature in Sharepoint 2010 is the Managed Metadata Service (MMS). The MMS allows the creation of multiple hierarchical descriptions of information that can then be applied to records across sites.

End users can also tag records with their own metadata which is then surfaced in the MMS, allowing it to be added to the rest of the organisation’s metadata as required. This is particularly useful when a new subject appears in the organisation.

In some ways, the MMS resembles folder names in Outlook or network shares. It is the way end users see their world.

Lesson for records managers: Understand how end users describe their world and how Sharepoint 2010 can capture that information. Recordkeeping metadata sometimes doesn’t make sense to end users.

Content Types

Content types are the main recordkeeping ‘currency’ in Sharepoint 2010.

Sites consist almost entirely of content types, including when a user clicks on ‘New – (Content Type)’ in a Library or List, or creates content in the form of a wiki or event.

Records managers who are familiar with TRIM record types will see a certain similarity with Sharepoint 2010 content types. But the resemblance is superficial and it would be a mistake to try to make content types behave like TRIM record types.

TRIM record types are generally few in number and mostly consist of documents, files (containers) and boxes. Retention information is generally applied at the file (container) level, and documents inherit that information. Documents are generally single, digital objects of some sort.

In the Sharepoint 2010 model, content can be literally anything. One way of thinking about content types is that each one can ‘map’ to a disposal class in a retention schedule.

Some content types can (and should) be created by customising the top level content type. This is because each content type can then have its own specific metadata and retention information.

Other content types, such as wikis and calendars, can be left ‘as is’ as they are likely to be managed and retained the same way across all sites. For example, calendars could all have a retention period of 2 years after last entry.

Records managers need to understand that *every* content type can be assigned two key elements. These are: (a)a range of recordkeeping metadata that is mostly invisible to end users, but can include end-user defined metadata, and, (b) Information management (IM) policies.

IM policies, and in particular retention policies, are one of the *key* differences between Sharepoint 2010 and 2007. This functionality is not overly obvious if you don’t know where it is or what it does.  It should not be confused with ‘expiry dates’.

The importance of getting IM policies right becomes more obvious when they are not configured correctly. When this happens, (such as by configuring the policies on the parent, generic content type), it can become impossible to do anything with them, and all records using the same content type could have either no recordkeeping rules applied, or it will be same regardless of the type of record it is.

This may not be a bad thing for generic types of records, such as calendars, but could be disastrous if every single document saved into the site collection has the same retention policy.

A *key* information management policy element is Retention. This check-box functionality is easily overlooked but it is a critical piece of recordkeeping as it defines how long the record will be kept. As noted already, each content type can (and perhaps should be) mapped to a class in a retention schedule (or to Normal Administrative Practice (NAP), for Australian government agencies).

Retention policies allow for multi-stage disposition changes to records. They also allow records either to be disposed of on a site after a given period, or sent to the Records Centre for review and/or disposal or further retention.

Sharepoint 2010 includes the US-style concept of ‘declaring’ something as a record. While this functionality is alien to most Australian records managers, it has potential use for allowing changes to the status of a record.

Records stored on network shares or in email folders provide a useful analogy. If the organisation has an EDRMS, end users must transfer the record from the drive or folder to the EDRMS. In most cases this process will leave the document or email in its original location.

The records declaration function in Sharepoint 2010 would allow for a document that is created or saved to a site as a ‘non-record’ (eg, a ‘working document’) to be ‘declared’ as a record on the site, resulting in a change to retention requirements for the same record, rather than expecting an end user to save it to a different system.

Information management policies also include the ‘auditing’ function, allowing auditing on a range of activities.

Lesson for records managers: Learn about Content Types and understand how Information Management policies work and can be configured.

Where are the containers?

Potentially one of the most confusing things about Sharepoint 2010 for records managers seeing the product for the first time is the apparent absence of containers.

Collections of document-type records can be stored in libraries. Libraries may contain folders (another content type) defined by users, or document sets which resemble containers.

It is important to keep an open mind about the concept of a container when learning about Sharepoint 2010.

The product offers multiple ways to organise records in a given context, including through libraries, folders and document sets, but also (and perhaps most importantly) through metadata.

The way end users organise their records is likely to depend on their (or their business unit’s) context. Different users, and records managers, may see the world in different ways and organise information accordingly.

Sharepoint 2010 provides the flexibility to meet these sometimes competing interests, including by allowing end users to organise information that makes sense to them, and then send it to the Records Centre at or after a given time, to be organised in a way that makes sense to records managers.

Lesson for records managers: Look outside the square at how records might be organised. Pre-defined containers are not necessarily the only option.

The Content Organiser

As noted above, information management policies in content types in Sharepoint 2010 can be used to define retention rules for all types of content.

In the same way that rules that can be applied in email applications to route emails to specific folders, the content organiser in Sharepoint 2010 can be used to route any content type to a specific, pre-defined location in the records centre.

This is done by using the feature to send the content type to a different location such as the records centre after a given period of time.

Lesson for records managers: Learn how content types work. If you are involved at the beginning of a Sharepoint 2010 implementation you have a better chance of setting up and configuring content types correctly so they will eventually be managed in the records centre. This can include the ability for records managers to review new, undefined content that is sent to a ‘drop off’ area in the Records Centre.

The Records Centre

The Records Centre in Sharepoint 2010 is, in effect, a separate site in the site collection (or farm) to store corporate records. An organisation may have more than one records centre.

The centre should be owned and managed by records managers. There are various ways to configure a records centre.

One option would be to create a library (or libraries) for records, each of which contains a pre-defined folder structure mapped to the organisation’s Business Classification Scheme (BCS).

As these folders can have IM policies applied to them, they can be mapped to specific classes in the organisation’s retention schedule. In this way, they start to look very much like containers!

As Sharepoint 2010 allows for retention rules to be applied to either libraries and folder OR content types, each of these folders can have retention rules applied to them.

Lesson for records managers: Own the records centre!


3 thoughts on “What records managers need to know about Sharepoint 2010

  1. You state “Some content types can (and should) be created by customising the top level content type. This is because each content type can then have its own specific metadata and retention information.”

    Can you explain how “each content type can then have its own specific retention information”? I have created a hierarchical content type structure. The top (enterprise) is based on the document content type but adds “enterprise” valued metadata. Then, we have a functional content type that is based on the enterprise content type and finally a department content type which is based on the functional content type.

    We have a requirement to assign an IM retention policy at the enterprise level for document created using this content type. We also have a requirement to assign an IM retention policy at the Functional level for documents created using this content type. And, you guessed it, we have a requirement to assign IM retention policies at the department level for document created using this content type.

    What we are experiencing is that the functional and departmental content types can NOT have their own IM retention policies since their partent content type (enterprise) has an IM retention policy and it trumps all children content type IM policies.

    Is there a way to enable each content type to have their own IM policies as you identified that we are not aware of?

    Note: We are using MMS and a Content Type Hub to publish and managed all our site content types. Perhaps this has something to do.

    1. Thanks for the comment Steve. I am not sure I fully understand what you have done, as opposed to what you want (or wanted) to do, so hopefully my comments are to the point.

      You have (at least) three document Content Types: Enterprise, Functional, Departmental. The last two are inheriting the policy that is applied at the Enterprise level.

      It usually goes without saying that you need to plan very carefully when creating document-based Content Types to avoid having to try to fix things up afterwards. So, I hope you haven’t gone too far in your production system.

      As I understand you, you have applied a retention policy of some sort in the Information Policies of the ‘top’ level Enterprise (document) Content Type. I am guessing you then created a new Functional Content Type based on the Enterprise Content Type (and so inheriting the policies), rather than creating a new Functional (and Departmental) Content Type from the top level, ‘base’ document Content Type. In other words, you did this (‘a hierarchical content type structure’):

      Content Type: Document – Enterprise -> Functional -> Departmental (and so inheriting down the line)

      instead of (a flat structure)

      Content Type: Document – Enterprise
      Content Type: Document – Functional
      Content Type: Document – Departmental

      If you have specific, common, recordkeeping (or other) metadata you want to apply to all three, then you could create an intermediary document Content Type based on the top level. So in other words:

      Content Type: Document – (Recordkeeping) Document – Enterprise
      Content Type: Document – (Recordkeeping) Document – Functional
      Content Type: Document – (Recordkeeping) Document – Departmental

      In all three instances, the Retention rule is applied at the Enterprise, Functional or Departmental level; there is no rule applied to the (Recordkeeping) Document, and so it does not inherit.

      Where I work now we are implementing the last model above. The intermediary (Recordkeeping) Document contains a series of recordkeepign metadata elements, some of which are populated (because they will always be the same) and some of which are empty (to be populated in the next level down). Our model (for one area, after careful analysis) is:

      Content Type: Document – (Recordkeeping) Document – Business Specific Content Type 1 – Business Specific Content Type 2 (with some extra metadata).

      In this case, CT1 is where the retention policy is set, so CT2 inherits it.

      On your last point, we are also using a Content Type Hub where *all* enterprise Content Types are created and managed. Site Libraries are then provisioned with Content Types from the CT Hub. Metadata in the MMS is applied, as required.

  2. Hey Andrew. Thanks for the reply.

    Interesting. I can say that you did understand my question.

    We are in a development, so we have no production data/structure to worry about.
    Now is the time to figure this out.

    The reason we created a hierarchical content type structure is because the work done defining metadata requirements at the “enterprise” level should not have to be redone at the “functional” or “department” levels.

    Even your “flat structure” is, in my view, a hierarchical structure because it is inheriting metadata values from the “Document” content type, but I do understand what you are trying to depict.

    Our Enterprise content type contains metadata elements that is the minimum any document should have which is whatever “Document” content type (OOB) has plus stuff like Keywords, Classification, Author (this is a new, custom text field the client wants).
    This content type would be used to create generic documents and also for incoming emails that we have no control over what metadata elements come with it.

    The next content type (functional) introduces additional metadata elements based on the function in question. But, it must contain and begin with the same metadata elements that the enterprise content type dictates. To eliminate duplication of work, we created this functional content type first by inheriting “Enterprise” columns.
    Same thing for the “Department” content type.

    This structure was developed to make the management of the metadata easy and concise.
    We have also defined three levels of management for each content type levels.
    We will have “Enterprise” content type admins and “Functional” content type admins and “Department” content type admins. This way, individual departments can meet their own metadata requirements all the while meeting the enterprise requirements.

    I can see where you are going with your intermediary content type but I believe this presents the duplication that I was trying to eliminate.

    Alas, my problem continues. I want to use the hierarchical structure of content types, but I need to assign different retention policies at each content type.

    We may have to look into a combined Content Type based IM Policy and Folder based IM Policy with the use of the content organizer within the record center.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s