I have worked with many clients over many versions of SharePoint and over the years the attitude to folders has evolved quite a lot. I am sure many of us remember certain colleagues who have been quite stubborn in their view that folders are the spawn of the devil!
In the beginning, there were file shares, with folder structures to categorise the content allowing to be found.
Let’s face it, we are all comfortable with folders if we are managing content in a file share, or on our machine. If we set up the folder structure, then we fully understand it and know how it is intended to be used. The way we use the folder structure the change over time as the content changes, but that is fine because we are in control of the structure.
Issues start to creep in when the folder structure is used by a team of people, and the evolution of the structure and membership of the team changes. It is not uncommon for the original rationale of a folder structure to be forgotten through churn of team members. This means that the structure will be evolved, but in a way that will not necessarily replace the original structure, just extend it. At this point the risk of not being able to find content or not knowing where to put it becomes a reality.
And of course, we have to acknowledge that the effectiveness of a folder structure is very subjective. I worked with one client who had a legal team of twelve who were all carrying out identical roles. When we examined how each of these team members were storing content, we found twelve completely different approaches to storing the same content.
And then came the dreaded metadata.
Selling the concept of metadata (data describing data) to end users was, and still is one of the most difficult elements of user adoption with SharePoint. It’s not that it isn’t useful, and it’s not that there aren’t many advantages that users can benefit from, it’s just that, for most, the folder structure is sufficient when it comes to metadata, and this SharePoint flavour of metadata sounds awfully complicated.
And then there’s OneDrive
Syncing a library to make it available in Windows Explorer - that sounds like a great idea, but there is no folder structure, just metadata. This kind of makes the synced content unusable.
So what are we to do?
Well, there is a solution that satisfies all requirements: use both! This may sound like we’re making work for ourselves, but in fact it isn’t like that at all, and in many cases, it will increase the chances of the SharePoint solution being successful.
SharePoint does support folders, in fact in supports them so well that they have particular capabilities that we do make use of in delivering solutions because it is the best option:
- Default metadata - each folder can have metadata default set on it so that documents created in the folders will automatically be tagged
- Security - each folder can have custom permissions set to allow specific users to have access
- Performance - folders can be an effective way of segmenting content to allow quicker access to the content
Case Study
Meet Contoso, a building contractor using Office 365. They have several requirements:
- They have multiple clients
- Each of those clients has multiple projects
- Documents need to be stored at client and project level
- Contractual documents are only visible to sales and account managers
- It should be possible to search for all documents related to a client and/or all documents related to a project
- The content should be available to some employees when they are on-site and offline
A possible solution is to set up a document library for each client. This will allow OneDrive for Business to be used to sync the content offline. The document library will have the client name metadata defaulted so that all content in the document library is tagged with the client name.
Within the document library a folder will be created for each project. The project name metadata will be defaulted for each folder so that content added to the folder will be tagged with the project name, and the client name from the library). The folders will also be synced through OneDrive for Business so they can be accessed in a sensible manner through Windows Explorer.
A folder can be added within each project folder and set to not inherit the permissions of the project folder so that the access can be restricted.
In this way a folder structure is used that defines the metadata and actually makes the user experience better as the user is not required to tag content with the client and project names.
Gotchas
As always, there are some gotchas. This approach works well in a document management solution. It allows a sophisticated solution to be built using out of the box capabilities.
Lists
Lists do not support the ability to set default values on folders.
Pages
The Pages library is created as part of the Publishing feature. As such it has very particular capabilities (and constraints). You can use folders, and you can set defaults, but you cannot set permissions, as the process of creating a new page requires contribute access at the root level of the library (See https://social.technet.microsoft.com/Forums/en-US/51144c18-bec7-427b-a22a-bda0573c5463/sharepoint-onilne-access-denied-when-creating-a-page-in-a-folder-under-pages-library?forum=sharepointgeneral)
Summary
Folders vs. metadata is a decision that is driven by the requirements of the solution, and the expectations of end users in relation to their experience of using the solution.
Neither option is always right or wrong and combining them produces results that are more flexible and more likely to be successful.