Back to Basics: Using Folder Structures in SharePoint Libraries

This is a topic that keeps on surfacing, and I don’t expect it to go away any time soon: When should we (if at all) use folder structures in SharePoint Libraries? As much as I hate to admit it, there is no simple answer. But personally, I don’t often see many compelling reasons to use folders in SharePoint.

Folders are essentially just another solution, or tool, to address a specific need; organizing files, or data, in some sort of logical structure, so that users can easily and/or quickly find the files or information that they are looking for. But using folders for this purpose with SharePoint would be much like using a modem to connect to the internet, while you had an Ethernet or WIFI connection readily available. Or storing your contacts on a rolodex, while having an electric organizer, PDA, or cell phone.

But if folders are so antiquated and inefficient, why does SharePoint gives us the option to use them? I can think of a couple of reasons, and have ran into some of them personally. I’ll elaborate on these a bit later, first I’d like to go over some of their limitations; some examples of why we should not use folders.

For starters folders are hierarchical in nature, and force us into a single structure per implementation; this alone has many implications. Consider the following scenario:

You’ve been given the task of organizing and maintaining manuals for specific systems within your organization (phone, fax, printers, copiers, voicemail, video conferencing, etc.) . Your organization is composed of several regions, each with specific divisions and offices in different locations. Not all offices share the same products or services (some do.) All of the offices share a common network. You’ve been given three simple requirements:

1. Group A needs to browse the files by location (ex. Region > Division > Office)
2. Group B needs to browse the files by product type (ex. Printers, Fax Machines, Copiers)
3. Group C needs to browse the files by vendor (ex. HP, Kodak, Lanier, Polycom)

You’d be in quite a predicament…. You could create a folder structure such as the following:

• Manuals
  • North America
  • South America
  • Asia
    • Division 1
    • Division 2
      • Office 1
      • Office 2
        • Phones
        • Fax Machines
        • Printers
        • Copiers

Which would satisfy the requirement of group A. But groups B and C would not likely be satisfied, and to make matters worse, you’d likely have to maintain duplicates of the same manuals (which you could possibly mitigate by utilizing shortcuts.)  But all in all not a very elegant solution, some might say it is quite the opposite.

Alternatively you could create a folder structure like this:

• Manuals
  • Phones
  • Fax Machines
  • Printers
  • Copiers
    • HP
    • Kodak
    • Lanier

This would likely meet the requirements of group B and maybe even group C. It would also do away with duplicates. But what about group A.

There are many variations to this scenario, and the requirements may not always be given up front. A specific folder structure may work well for a period of time, and suddenly change; management may decide they want to view files in a different way.

But why would you try to use folders in the first place, when you could rely on views? Views would meet any one and all of these requirements. The information captured in the folder names should be stored as metadata with the specific files. You could then create a view that groups by; Region, Division, and Office; another that groups by Product Type; and yet another that groups by Vendor. Given the right AD groups and putting a little extra work towards setting up audiences, and you could create a page that automatically shows a different web part with the correct view for each group.

Some other reasons not to use folders:

1. If you are basing your folder structure on your organizational hierarchy; keep in mind that these hierarchies can and often do change. Something much easier to manage using site columns, and views.
2. If you do have to change the value of a Region, Division, or Office; which you’ve happened to use in your folder structure. Any links, bookmarks, or shortcuts to these files would probably break as the folder names form part of the Url.
3. Folders increase the length of the Urls, which can cause errors after reaching a certain limit.
4. Get your users thinking outside the box. Giving your users a couple of views that have properly named helps them think of other ways to look at the data. Even when your views closely resemble a folder structure. For instance giving them a view named “Products by Region”, lets them know that they could just as easily have a “Products by Office”, “Products by Type”, or “Products by Vendor”. And that they themselves could create similar views for the data they are responsible for in SharePoint.

So why does SharePoint offer folders in the first place, if you can just as easily and more efficiently organize your data with views? The following are a few scenarios where I’ve seen folders come in handy:

1. Folders make it easier to apply different set of permissions to logical groups of files within a single library. However, keep in mind that this can and often should be accomplished by using different libraries. If you are worried about consistency across the libraries; consider using content types, or a library template.
2. Copying files from libraries in bulk (using explorer view) and keeping some sort of logical structure. In my experience I don’t often see many scenarios that require users to copy files in bulk. While certain users may have the need to do this every once in a while, consider the repercussions, and remember that you should be configuring your library for the norm and not the exception. If copying or moving files in bulk happens to be the norm if your scenario; consider creating a new sub site for the group as a whole and splitting the files up into multiple libraries within that sub site.