15 Reasons Not to Use Folders in SharePoint (and 3 reasons why you could)

I hate folders as a means of organising content. It’s a deeply broken approach and carrying it over to SharePoint is one of my pet hates. I have even written a song about it. So I pulled this together from my involvement in various conversations and involvement in a discussion arising from an article written by Gregory Zelfond. http://sharepointmaven.com/12-reasons-folders-sharepoint-bad-idea/

1. No right place – this is the biggest issue and most easily understood; folders force you to put a document or file in a single location, even if it might legitimately be associated with several places. A project report could be put in a folder with all the other documents for that project, or in a folder for reports, or in a folder for documents that are archived; in reality it should be in all three but that creates duplicates. SharePoint metadata would let you tag the document as being a Report, associate it with a Project, set its status to Archived and more. Different views would let you see (or hide) all Archive documents, all project reports, all documents that are not in draft that have be modified by me in the last 7 days and include the Technology tag, etcetera, etcetera. And you can switch between views with a single click.
2. Usability – Unless you have a rigorous and actively managed file plan (and, let’s face it, no one actually does this well) then the folder structure is only known to the person/team who created it. Everyone else has to inefficiently browse the contents hidden in the folders in the hope of finding the document or file.
3. URL length limitation – SharePoint builds the URL using all folder and sub-folder. However the URL length is limited to around 255 characters; beyond that you get an error. Deep folder structures simply break in SharePoint.
4. Unfixed URL – Moving a file from one folder to another changes the file URL, so any fixed links to it will break.
5. Security – You can use folders to define security for groups of files in SharePoint, however ongoing management of this is as big an administrative nightmare as it is on file servers.
6. User experience – The user experience (UX, navigation, finding the documents) is marginally worse than it is on file servers – it’s slow, content is hidden until you open the folder. Moving content within folders is terrible within the browser, navigating between folders is horrible too. (though you can open the library in Windows Explorer).
7. File duplication – Folders actively cause file duplication, partly because there is no one, right place for a given document or file (in fact you often have to put a file in multiple paces because folders are so inflexible), partly because you can’t see that the file already exists elsewhere. If you are striving for a ‘single version of the truth’ then creating duplicates immediately undermines this principle.
8. A single view – One of SharePoint’s many great features is the ability to have multiple views of content, with the flexibility for users to filter and modify the view on an ad hoc, temporary basis. But not with folders, in a folder view you get just one view of your content and it is pretty poor, for the reasons above and below. Using metadata, you can create unlimited number of views by whatever properties you have setup (i.e. organize documents by date, by customer, by project, etc.) .
9. Can’t Sort & Filter – Burying files in folders means you can only benefit from the sorting and filtering capabilities of document libraries and metadata navigation within the folder you are in.
10. Inflexible – It’s hard to change the folder structure (though again you can use Windows Explorer), while changing metadata is easy and can be done as bulk actions.
11. Lost documents – It is so very easy to misplace documents by putting it in the wrong folder and not knowing where it is. So then you create a duplicate copy, and the mess begins.
12. Navigation – When you are in a particular sub-folder, there is no easy way to tell which folder you are in and no easy way to navigate to the parent folder, a sibling folder etc. since there is no breadcrumb trail or tree view by default.;
13. Cost – If all you are doing is recreating the same mess of nested folders you had on file share within SharePoint all you have done is increase the cost (SharePoint infrastructure is more expensive than a file server) and you have cunningly avoided almost all the benefits of SharePoint.
14. Visibility – the only way to know how active a folder is/how many documents it contains is to open it. It could be empty; it could have ten thousand documents; you just don’t know. A grouped SharePoint view in SharePoint using metadata shows many docs are in each group (and lets you carry out counts and other basic arithmetic on column values, such as Average file size). If there are no items in a group then the group doesn’t clutter up the screen.

    

15. Data Integrity – There is little control over the naming of folders, so you can have spelling errors, non-standard conventions, unhelpful abbreviations etc. Metadata driven views can be driven by lists and taxonomies to avoid this.

Exceptions

The big problem is that folders are traditionally used to categorise content, whereas they were originally designed to group content. Just because we have learned to use folders inappropriately doesn’t mean we should continue to do so. However folders have some legitimacy for their original purpose. If you genuinely need to group files together then you can use a folder in SharePoint; this is usually because you need to perform a group action on them, such as delete them all. Similarly folders may be used (despite point 5 above) to assign grouped security to the content – simply moving a file into the folder gives it some security; as long as the security rules are very simple to apply and understand. In both cases you still should avoid folders – use a Document Set instead, since they are much more powerful, intelligent and intuitive. Even then we strongly advocate having only a single level of folders and never, ever more than two,

The only other reason for retaining is that you can’t get users to adopt the new, better way of doing things. At this point you have to use your judgement – generally staff work for the company and the company can dictate ways of working; there are rules for not operating machines without guards, even though they can be somewhat inconvenient for operators (until it saves one losing an arm); the digital health of your knowledge is as important. However if a team or individual chooses to stick with folders for their own content then that may be OK; as long as it doesn’t disadvantage other staff and that they aren’t wasting company resources (working time, support desk resources, computing time) in the process. A suitable policy for use of your intranet can address this – shared content, core business processes, managed information should not allow use of folders in libraries; personal and team working areas may use folders, but should avoid deeply nested folders, should also use flat views (where the folder structure is hidden) and must be actively managed by the team to avoid duplicates and misfiling.