Moving from File Shares to Sharepoint Lists

What were the key features of File Shares

File shares allow users to store content in a location where several users can collaborate on that content. The content can be;

  • shared
  • categorised by using folders
  • secured with different permissions for different users
  • searched for by filename, file type, date modified, and author

Key issues with this approach have been;

·        the difficulty of finding individual items with the search/structure available

·        lack of versioning

·        Management of permissions

·        Inability to report on the data you have

·        No summarisation of the data

·        Backup

·        Restoration of Deleted items

·        Lack of auditing

·        How to apply compliance procedures

What does Sharepoint give us?

We wouldn’t be moving to Sharepoint unless we got some improvements on the fileshare situation, so what are they? We suddenly get the following available to us in our Document Management environment;

  • Enterprise Grade Search
  • Versioning
  • Backup
  • Recycle Bin
  • Robust Security Model
  • Audit
  • Workflows aiding Compliance, Approval, Disposal et al
  • Reporting
    • Key Performance Indicators
    • Aggregation of data in e.g. Content Query Webpart
  • Grouping, Filtering, Sorting in Views which can be public or personal

How should my content in a Sharepoint Document Management scenario differ from File Shares?

First thing to say is that the whistles and bells in Sharepoint could be largely ignored. You can create folders in lists and put your content in it, job done. Heck, you can even link to Sharepoint lists in Windows Explorer and drag your folder structure and files into Sharepoint. At a basic level this just works and it’s fast. You could then spend a further 5 minutes turning on versioning, audit, and having a reassuring chat with your System Administrator that backup is in hand, and you have business benefits to demonstrate for your Sharepoint investment. Job done huh?

The problems begin when you start to get the same user complaints about Search, Managing Security, and new complaints that they can’t filter, sort or group those new fangled list views on anything particularly useful and that they can’t selectively apply workflow to some items but not others. The users are unhappy, they had to switch over to using this slick new product and its still all the same old belly ache with a few extra pangs.

The folders you ported from your old environment are pretty harmless. The main problem is that when they ported the old folders over they also ported the old way of thinking about data over too. Sharepoint thrives on metadata, i.e. that extra information about your data. Put some work into that and the true bounty of Sharepoint will follow.

How to get more benefit from your Sharepoint data

Some basic governance rules;

  • Create meaningful filenames for your content with spaces separating the words, i.e. prefer ‘Joe Bloggs 2009 Resume.doc’ over ‘Resume.doc’.
  • Fill out the document properties in your MS Office documents, especially Title and Author, and preferably description.

That quick hit has just helped your Enterprise Search find much more relevant results than it possibly could before.

Moving on, we need to start planning content types for our content. All your content will have a default content type already if it’s in Sharepoint, but it’s probably not specifying much additional data. Have a look at your old folder structure, and it’s likely to suggest candidate columns for you content type right off.

Consider the following simple folder structure;

Looking at the nouns in there suggests candidate columns for the Content Type. You can see ‘Year’, ‘Expense Type’, and ‘Document Type’ if you squint hard enough.

Adding these columns to a Content Type suddenly allows users to sort, filter, and group by those fields in the list views. Things start getting much easier to find. In addition, search crawls those columns and gets more relevant results when someone searches for ‘Travel Receipts 2008’ than if you only had the folders with no metadata specified.

On top of that, lets say you created a Content Type called ‘Personal Receipt’ just for the above documents. Your compliance guys come in and say that the receipts contain personal data and have to be purged exactly three years to the day after they are created. You’re now in the happy position where you can attach a custom workflow to the Content Type ‘Personal Receipt’ to ensure that’s exactly what happens. Just try doing that when the documents are in plain old folders and see how easy it is.

So is it Folders or Metadata?

The point is that folders are largely irrelevant in Sharepoint 2007, as long as having them doesn’t prevent you specifying the metadata for your content. That metadata makes life much easier. 

Personally I find folders a little annoying in the User Interface, repeatedly clicking down the hierarchy to find something. Then there are other users who prefer such hierarchical navigation. If there’s a list with lots of folders that I’d rather work with using a List View I can do it. I’d simply create a View and in the Folders section of the view settings I’d select ‘Show all items without folders’. This flattens all the data as if the folders aren’t there. As long as there is metadata to filter on everything is golden.

So, is it folders or metadata? Have both. If you specify your metadata well, you may not even need folders, but they can coexist perfectly happily.

Disclaimer: The software, source code and guidance on this website is provided "AS IS"
with no warranties of any kind. The entire risk arising out of the use or
performance of the software and source code is with you.

Any views expressed in this blog are those of the individual and may not necessarily reflect the views of any organization the individual may be affiliated with.