SharePoint 2013: Folders vs Metadata Views

2017-12-11T10:23:15+00:00 January 2nd, 2015|Sharepoint|

The MVPs have an excellent write up about the advantages and disadvantages of Folders in SharePoint 2013 with a great “versus” section:

http://social.technet.microsoft.com/wiki/contents/articles/16166.sharepoint-2013-using-folders.aspx

It comes up all the time in the SharePoint world, and while it’s easy as a consultant to play the “this way works best” card, in this post I wanted to provide some useful information to help you understand how we might base a starting point for planning and justifying the decision to use Folders or Metadata Views.

First thing to understand is that contrary to what some people believe, the RFC definition for HTTP does not actually state a maximum URL length, rather the limits are imposed practically by software (be it on the server or client). So to add some context to this post, please allow me to quickly list a few examples of some practical limits.

Web Server Software:

  • Internet Information Services – from IIS 6 onwards, the default limit is 16384 characters, but is configurable
  • Apache – I haven’t found a definitive answer for this, but by default 8190 bytes is configured (see LimitRequestLine directive link below if you fancy testing this yourself)

Client Web Browsers:

  • Internet Explorer– from MSIE6 onwards, the path portion of the URL can not exceed 2083 characters with no more than 2048 in the path portion
  • Firefox – from 1.5 onwards, Firefox doesn’t seem to have a limit. 65536 characters will be visible in the URL field but I’ve seen claims that URLs will work well beyond the 100k mark!

So in layman’s terms, there is a mix. An easy and widely used recommendation to establish from this information is that “no URL should exceed the 2000 character mark”. For customised web applications, it’s quite common to adopt the gzip algorithm to compress long URLs, which would yield gains of 3-4 times but the trade-off is that it will cost you CPU time to re-encode that binary data into base64 during the URL unzip process. That might sound out-of-scope for the SharePoint world, but consider the options that SharePoint gives us for integration and surfacing with other LoB systems, this might be a real world question that needs answering.

Now, let’s jump back into SharePoint mode (in fact this next paragraph is true for Office 365 too). Link items in Lists are restricted to 256 characters, any more and SharePoint will truncate it. For Libraries, the entire path (including sites, folders, and file name) cannot exceed 260 characters, any more and users will receive form validation errors. Here are another few maximum length boundaries for some key portions that make up a SharePoint URL to finalise the calculations you’ll need for URL length planning:

  • Site – 128 characters
  • Library / List – 255 characters
  • Folder – 123 characters

So in a roundabout fashion, URL length is a good place to start with planning as a technical limitation would always over-ride any “nice to have” requirements. In short, know that if you exceed that magic 260 character limit, SharePoint might break. So generally speaking (and it doesn’t have to be an exact science), if URL length even pops up as a consideration then go for Metadata Views, not Folders.

The second planning point could be centred around the metadata itself. SharePoint adds metadata to your uploaded documents whether you want it or not. This is a good thing, because without having to do anything at all you could build a useful Metadata View and abolish Folder structures. Making a really awesome Metadata View however, requires a little more consideration to your overall Information Architecture, taxonomy, mandatory / optional metadata, etc. Chances are, traditional file systems with a folder hierarchy can be quickly replaced by Metadata Views which nearly always results in users being able to find the right document, faster. A common trade-off here is the time required to plan and deploy the metadata strategy (including user training). In almost all scenarios though, Metadata Views trump Folders for both usability and repeatability (you’re using the Managed Metadata Service Application and Content Type Hub, right?).

The third planning point should address permissions. More accurately, how granular do your permissions need to be? Many organisations have permissions inheritance broken at the Library/List level, and while this serves most applications, it may be necessary to break this down even more (or maybe you don’t want multiple Libraries/Lists). By a long shot, it is more effective to apply permissions to Folders than it is to individual items – not to mention the administrative burden of managing item-level permissions. So unless you are happy to buy third party software (or develop your own solution) that can apply item permissions based on metadata, it stands to reason that Folders trump Metadata Views in this instance. Personally, I try to avoid breaking permission inheritance any lower than the Library/List level.

Summary

In all honestly, you are likely to need a mix of Folders and Metadata Views, usually driven by the planning of URL lengths, metadata requirements, and granular permissions. There are, of course, other concepts that may need to be considered so please only use this information as a primer to get you started.

Further Reading

The Internet Engineering Task Force completed publications for the revised HTTP/1.1 can be found here:

Information about the Apache “LimitRequestLine” directive can be found here:

URL path length restrictions for SharePoint 2013 can be found on the following TechNet article (note, at the time of writing the SharePoint 2010 guidance applies to SharePoint 2013):