Posted in Electronic records, Information Management, Records management, Retention and disposal, Sharepoint 2010

Sentencing and disposing of records in SharePoint 2010

This article applies only to on-premises installations of SharePoint 2010. 

SharePoint’s ‘Records Centre’ was, in theory, a place to send records from various sites for long term storage, sentencing and disposal. The idea was that you could automatically, via Content Type rules, or directly, via the ‘Send to Records Centre’ option, transfer records out of team (and other) sites into the Records Centre. 

While the theory made sense, in practice there were several problems with the model, not the least being that ‘transferred’ records were not actually transferred but copied and effectively re-registered as new records in the Records Centre. They also lost previous versions, and so on. 

We needed to find another way to manage the sentencing and disposal of records. SharePoint 2013 has the (information management) option to apply a sentence on an entire site, which is great if you want to do that, but in most cases the requirement is to sentence parts of a site, including whole libraries or lists. 

As our document-based records are stored in document libraries, and these libraries generally (but not always) have names that make sense (if you can stop people using the generic ‘Shared Documents’ default library), it seemed a good idea to focus on how we could apply retention and disposal policies to document libraries. 

The first problem is visibility of all those libraries, created across multiple site collections. The only way to see all of them was to be the SharePoint Administrator or have Site Collection Administration privileges across all sites. But it was cumbersome to have to open every site to see what was stored in them. 

I put this problem to our SharePoint Administrator and developer (Eric Fang – blog here: http://fangdahai.blogspot.com.au/) . Using PowerShell scripts, Eric developed a method to display all document libraries across all Sharepoint sites in a list. The list updates on a regular basis.

NOTE: You cannot create this type of list ‘out of the box’, it requires PowerShell scripts, and that will need to be maintained over time. This is not a skill that is normally found with most SharePoint Administrators. 

The list displays:

  • The library GUID
  • The library name and URL
  • The site collection and sites, including URLs
  • The number of items stored in each library
  • The date the library was created and who created it
  • The date any item in the library was last modified

The first, immediate, benefit we could see from this method of displaying libraries was the number of libraries that had been created but not used. We could immediately see the ability to reduce the number of libraries, especially if these had not been used for a given period (say, one year).

The next benefit was the ability to group libraries by site collection. As many of our site collections map to business functions, we could start to see the volume of content that was stored for each function, by library – many of which were created to store documents created through various activities.

For example, a common document library is ‘Meetings’. We can now filter the view to see all libraries that contain documents relating to meetings. We can also see types of libraries that have specific retention and disposal requirements.

While the list of all libraries has provided an excellent way to view all our libraries, we are now working on a method to apply retention and disposal actions to these libraries. One way to do this would be to add an extra column in the list for retention and disposal information (class number, class decription, disposal action, expected disposal date, approved by, etc).

Once a disposal action had been applied to the list, we can then review it when the disposal action became due to determine if the library could in fact be destroyed. If it can be destroyed, it would be possible to export the original library metadata columns to a spreadsheet to keep a record of what was destroyed, and when.

Posted in Access controls, Electronic records, Products and applications, Records management, Sharepoint 2010

Planning access controls in SharePoint 2010 team sites

A key factor that needs to be considered when planning for the creation of team sites for the management of records is access control. Getting this right (or as close to right as possible) early on for team sites with sub-sites will save a lot of potential pain later on.

Team sites will normally have three levels of access permission:

  • Site owners. Full control. One to three for each site collection.
  • Site members. Contribute rights, i.e., add/edit/delete.
  • Site visitors. Read only access.

There are generally three ways to manage access controls in team sites that have sub-sites:

  • Inheritance, broken as required. Top level site owners control all sub-sites, site members and visitors can be the same.
  • Independent, within a site collection. Different site owners/members/visitors between the top site and sub-sites – although the site owners could be the same.
  • Independent, separate sites but linked. Different site owners/members/visitors for each site.

Inheritance model

This is the default access model for team sites with sub-sites and is enabled when a Site Administrator creates a new sub-site without choosing ‘More options’ on the ‘Create’ Team Site dialogue page. Site owners control the top and sub-sites, site members and visitors are the same unless inheritance is broken on any part of the site (sub-sites, libraries or lists, or documents).

  • The benefits of this model is that site owners control all the site collection and both members and visitors can be the same.
  • The negatives relate to the effort involved in restricting access and giving unique access to sub-sites, libraries/lists, or documents. For example, to provide access to a specific area, a person who is not part of the default members or visitors group must be either added to one of those groups, or added individually. When they are added individually by user name, their user name appears across the entire site collection; they will be able to navigate ‘up’ (and down) but they won’t see any content in any page, library or list. Another negative is that, once selected, it is not possible to revert to the independent model (unique permissions); it is only possible to break the inheritance model and create new security groups which is a bit messy.

Independent model, within a site collection

The option to select this model must be selected when the new sub-site is created by clicking on ‘More Options’ after the Title and URL name are entered. A new dialogue box opens with a section ‘Permissions’. This notes ‘You can give permissions to access your new site to the same users who have access to this parent site, or you can give permission to a unique set of users’. It adds, ‘If you select “Use same permissions as parent site”, one set of user permissions is shared by both sites. Consequently, you cannot change user permissions on your new site unless you are an administrator of this parent site’.

There are two options:

  • Use unique permissions
  • Use same permissions as parent site (the ‘inheritance’ model above).

Again, there are positives and negatives to this model:

  • The benefits of this model are that you can have unique access permissions on sub-sites, removing the requirement to break inheritance or worry about what users with access can see on the other parts of the site collection. Each sub-group within a team can have their own site that cannot be accessed by the other parts of the team – although you might consider giving other parts of the team visitor access, with the sub-group having ‘contribute’ rights.
  • The negatives of this model are in the requirement to manage multiple access permissions for the top level site and sub-sites. Consider a common team environment – normally only a couple of people will be the site owner. If the site collection has multiple sub-sites with unique permissions, each of those sub-sites will have their own site owners. Of course, you can assign the same person to the site owner of each sub-site, but it is still a degree of overhead you don’t get with the inheritance model.

Independent model, separate site collections

This model simply consists of either of the first two options, with separate site collections added as links either on the global (top) or current (left hand side) navigation. End users don’t know that these links are completely separate sites unless they look at the URLs.

  • The benefits of this model are the same as the benefits for the second option above (independent model). Each site collection has its own unique permissions. It also allows you, if you restrict team sites to one sub-site level, to have sub-sites on the linked sites, to get around that restriction. Separate site collections could have either ‘open’ access to everyone, or ‘closed’ access.
  • The negatives of this model are also the same as the negatives for the second option above. Generally, however, there will usually be a good or compelling reason for having a completely separate site collection linked to the primary team site, and this often relates to the proposed site audience. For example, members of the team may be involved in a project; the (separate) project site can be linked to the main team site, but only those members of the team site with access will be able to see it.

In summary, it is important to consider access controls carefully, understanding both the benefits and the negatives of each option, then plan and implement accordingly. Otherwise, if there is a requirement to change the access type, this could be difficult to implement later on and the sub-site may have to be re-created.

Posted in Electronic records, Products and applications, Records management, Sharepoint 2010, SharePoint 2013, Training and education

Is your SharePoint team site a ghost town?

One of the best ‘unknown’ (to end users, anyway) features of SharePoint 2010 and SharePoint 2013 is ‘Site Web Analytics’, hidden away under Site Settings. This, out of the box, feature provides useful information such as the average number of site views per day, the average number of unique visitors per day, trends, as well as a listing by user names of the top visitors and the number of their page views. It’s a great way to see if a site is being used.

The default date range for Site Web Analytics is the past 30 days but the settings can be changed to the last day, week, month, quarter, half-year or year. Custom dates can also be set, and these reports can be exported to a spreadsheet for further analysis, including through scheduled reporting sent by email.

So, what does this have to do with the subject – is your SharePoint team site a ghost town?

Simply, Site Web Analytics tells you if your team site is being used – by your team. If it’s not used, then it’s a ghost town – and you need to understand why and consider changing or deleting it.

In many cases, the reason a SharePoint site becomes a ghost town is because users simply neither want nor know how to use it.

What makes a document management system popular?

My experience implementing and using many other document management systems (TRIM, Documentum, iManage, Alfresco) over the years, along with considerable anecdotal evidence, suggests that, unless there are legal or regulatory requirements mandating it, end users tend to baulk at using a document (and records) management system, especially if it:

  • Requires more than 20 minutes to learn. Some EDMS systems require hours of training – for end users!
  • Duplicates what they do already with network drives. More often than not it requires ‘saving’ an existing born-digital record to the recordkeeping system (AND leaving the original where it was stored).
  • Stores records of a business activity away from other, potentially rich, related records that are not documents.
  • Provides no obvious or little tangible business value for the user – it’s a ‘compliance overhead’.

A popular document management system is one that:

  • Users can start using the system with very little training. It should be intuitive and make sense at first glance. I often use the example of Facebook – no-one ever got training to use it and yet a billion people registered to use it.
  • Reduces (not necessarily eliminates) duplication of effort. Network drives can still exist to create and manage ‘working documents’ instead of final versions.
  • Can keep records in context with other related records such as calendars, lists, tasks, announcements, social networking messages, and so on.
  • Provides tangible business value for the user, with minimal effort. It’s hard to break the network drive habit but simple things like unique document IDs, versioning, hyperlinks, and the ability to email a link instead of a document help to break that habit.

What can turn a SharePoint team site into a ‘ghost town’?

Microsoft clearly put a lot of human-computer interaction (HCI) effort into the user interface design of SharePoint team sites (along with all their other products). Team sites in SharePoint 2013 are a design improvement over SharePoint 2010 but still maintain the same essential look and feel, which is:

  • Document libraries and lists on the left hand side navigation. It’s no coincidence that this is exactly where network drives and email folders are accessed from.
  • An editable main page that can be modifed as required to present additional information or options, including via webparts.
  • Default and modifiable views of documents and lists.
  • A simple search option on the top right.

Over 25 years of network drive use has conditioned users to navigating for documents from the left hand side, searching from the top right hand side, and seeing information presented in the middle of the page. Change this paradigm and you start to lose users.

I believe there are two main reasons why users don’t or stop using team sites (described further below):

  • The ‘plain vanilla’ out of the box functionality in a brand new team site.
  • Site pages that have been customised to the point where end users cannot work out how to navigate or access their information.

Out of the box generic functionality

Out of the box team sites include the two features which, if not addressed or re-configured (a 2 minute job), can negatively affect take up rates:

  • ‘Shared documents’ under ‘Libraries’. This to me is a ‘bookmark’ library that should be removed almost immediately and replaced with a library that has a name that makes sense, ideally named after a business activity. Otherwise, ‘shared’ is like ‘general’ in a network drive. If users have only one, generically-named library to choose from, they are unlikely to use it (compared to the rich tapestry of their network drives).
  • Folders. Unfortunately, while SharePoint folders look like network drive folders they don’t work the same way. They create unnecessarily long URLs and are often impossible to navigate. It’s not uncommon to hear users say they cannot find documents in a site because they cannot work out how to navigate folders (as they don’t include a + to guide navigation). My recommendation is to turn them off under Advanced Settings after the library is created. However, users inevitably want a way to categorise or group documents in a document library. Document Sets generally make sense to users and get quick take up but you can only have one level. A good site has a reasonable number of smartly-named document libraries – perhaps no more than 10, grouped as required by Headings – using Document Sets instead of folders. Another form of categorisation is using categories in the document metadata and then creating a view that groups the documents by those categories.

Customisation

Too much customisation of site pages can also turn users off. As noted above, it’s worth keeping in mind that Microsoft spent a lot of effort (and probably dollars) on designing their standard team site user interface. Some of the common modifications I have seen on ‘ghost town’ sites include:

  • Using themes that make the site look completely different from all other sites. It’s important to maintain consistency in themes.
  • Using unnecessarily large font sizes on the page.
  • Using too many images or graphics on the front page.
  • Assuming the text or content on the page is actually of interest to the target audience. I usually suggest that Site Owners (note, there should never be just one) agree among themselves; if this is not possible, test the proposed page design on a user who has never seen it.

Avoid ghost town sites – keep users coming back

Remember, most users are familiar with using network drives and folders. Use document libraries with sensible names that are obvious to users, don’t use folders, and keep the front page content simple and easy to view, and you are more likely to attract users back again and again.

Posted in Electronic records, Products and applications, Records management, Retention and disposal, Sharepoint 2010, SharePoint 2013

Managing Physical Records in SharePoint 2010

It is sometimes said by records managers that one of the drawbacks of SharePoint 2010 (and SharePoint 2013) is that it doesn’t manage physical records, or at least not very well.

This article describes how to manage physical records in SharePoint 2010/2013 using a list that includes barcodes.

Up front and out of the box, the main limitations are the ability to: (a) print labels for paper files and boxes (including labels with barcodes) (b) attach a portable scanner to scan barcodes and (c) maintain a chronological history of file movements. These limitations may not be a problem for many organisations seeking a low-cost way to manage mostly inactive files and boxes, especially if they currently use an Access database or Excel spreadsheet to do this now.

Options to address each of these limitations are discussed in this article.

Metadata options

There are almost no limitations on the type of metadata you can use to describe physical records. I would suggest having the following metadata:

  • Title (e.g., name on the file or box)
  • Record Type (drop down list – file, box, etc)
  • Reference ID (manually entered unless you use the default ‘ID’ option, possibly with a separate ‘year’ column)
  • Date created (date first registered, default system date)
  • Start date (start of date range)
  • End date (end of date range)
  • Business Owner
  • Current location (can be a custom list of pre-defined locations)
  • Date at current location
  • Record status (drop down list: active, inactive, missing, destroyed etc)
  • Internal barcode (if one exists)
  • External barcode (usually the one provided by a storage provider)
  • Records description (description of contents, usually of a box)
  • Box number
  • Box barcode (may be the same as the Internal or External Barcode)
  • Retention schedule (can be from a pre-defined list)
  • Disposal action (can be from a pre-defined list)
  • Date to be destroyed (manually entered based on retention schedule and disposal action)
  • Destroyed? (checkbox)
  • Date destroyed (manually entered date)
  • Legal hold? (checkbox)

If physical files are registered in the system, then only details of the box and disposal action would need to be entered. When the box is ready to be sent offsite, details from the offsite storage provider’s label (often provided in advance) can be entered in the external barcode and other metadata (including current location) updated.

An optional barcode can be obtained by checking ‘Barcode’ in the Information Management Policy settings for the list item. Once checked, the barcode appears when the item is displayed in view but not when it is edited or exported.

Printing labels

All list metadata (except the barcode) can be exported to an Excel spreadsheet, which can then be used to print labels. Microsoft provide details how to create and print labels for a list in Excel here:

Scanning

Using a portable (or attached) scanner to scan barcodes and update your records register, especially with a new location (or during a physical records audit) saves a great deal of time instead of entering details manually. It is possible to scan directly to an Excel spreadsheet however several steps may be required to match or validate the barcode with the details in the SharePoint list.

For example, if series of files are being scanned to a box (or location), the usual practice is to scan the box (or location) barcode first, then scan each individual file. If scanning directly to an Excel spreadsheet, you would do it the other way around – have the list of existing files in the spreadsheet, then scan the box or location barcode to the cell next to the file number. This detail can then be copied and pasted back to the SharePoint list.

Chronological movement history

The only option to maintain a chronological movement history, out of the box, would be to add versioning to the list. This means that each time the item is edited, a new version is created, keeping the previous details. The movement history will not display in a single view in the list but clicking on ‘Version History’ will show any changes made in single view. Only ‘major’ version numbers are supported in lists (i.e., 1, 2, 3, 4).

Posted in Electronic records, Products and applications, Records management, Retention and disposal, Sharepoint 2010, SharePoint 2013

SharePoint 2010 – Send to Records Center / Centre

SharePoint 2010 includes the option to send a document from the site where it was stored to the Records Center (Records Centre in Australia), and other locations. The option is set at the Central Administration Web site under General Applications – Configure Send to Connections. See http://technet.microsoft.com/en-us/library/ee424395(v=office.14).aspx for the details of how to configure this option.

The ‘Send to action’ list offers three options when a document is sent to the Records Centre (options which are then available across the farm):

  • Copy the document (which simply makes a copy)
  • Move the document (which appears to remove the document entirely. Microsoft state that ‘users will no longer be able to access the document from its original location’, suggesting it is not actually deleted from the original location)
  • Move and leave a link (see below)

Microsoft state (in the link above) that this option will ‘… delete the document from its current location, move it to the destination repository, and leave a link at the current location indicating that the document has been moved’. If Document IDs have been enabled, the Document ID will disappear next to the document icon, which then shows a hyperlink ‘hook’ to the document in the Records Centre. A user clicking on that link will be advised that the document has been moved.

The impact of versioning, and metadata, on ‘Send to’ moves

There are a number of issues, and potential problems, with the ‘Send to ‘ move option that need to be understood. Some of these might be sufficient to decide against using the Send to Records Centre option (or even using the Records Centre).

  • Versioning. If versioning has been applied to the document library, and versions exist, only the most current version will appear in the Records Centre. The Document ID will be the same as the current version. However, any previous versions remain in the original library. In one sense, it is good to show previous versions, however any of these previous versions can be restored. When this happens, the version that is restored now appears, with the original document number (and a ‘hook’ still on the icon). The logic of this appears to be that, if a previous version is restored, the version that has been sent to the Records Centre is no longer the current version. However, it remains – with the same Document ID – in the Records Centre.
  • Metadata. Any additional, local metadata that has been added to the Content Type in the original Site Library will disappear when the document is moved. Metadata in Content Types stored in the Content Type Hub will remain.
  • Created date. The ‘Date Created’ field in SharePoint is the date the document was created in SharePoint. When the document is sent to the Records Centre, it is assigned a new ‘Date Created’. The date created field on the original document remains unchanged.
  • Permissions. Any permissions that may have been applied to the document, via inheritance from the Library or Site, are removed and the document inherits the permissions of the relevant library in the Records Centre.

The implications for ‘Send to Records Centre’

The issues documented above could affect planning and decision making regarding use of the Records Centre and the ‘Send to’ functionality. Some issues to consider include:

  • Loss of versions when the document is moved
  • Ability to restore a previous version (and confusion about which is the current version)
  • Loss of metadata applied locally to content types
  • Changes to access permissions

If any of these are concerns for the organisation, consideration might be given to leaving documents in place where they were stored and managing them in that way. The Record Centre could instead be used to archive and apply retention policies to content from network drives.