I just came across a group post on LinkedIn this morning about the use of folders in SharePoint document libraries. I made a decent response via my phone, but I wanted to make a proper post.
Current best practice for SharePoint – few folders or no folders?
The last time I looked at SharePoint architecture best practices, the thinking was that it was ok to have a few folders, but that the bulk of data should be in one big pile and filtered through metadata views instead of distinct folder locations.
Has that thinking changed, or is the best practice still to use views predominantly?
You can have the best of both worlds. You have at least two audiences for each library, the ones adding to it and the ones retrieving from it. If you have an old school records manager who works with your paper records, ask them about folder structure. I’d say that if your library has folders, you should do it the same way you would on paper. When was the last time you went to a filing cabinet, opened a folder, and saw more folders inside of it? If you have files at the same tier as folders, it is like putting papers on top of the cabinet because you don’t know where they belong. When you create a folder structure that goes nine nested folders deep, you really hide the content from the person looking for it. Even if you assume that anyone needing this could use search, you’d be fooling yourself. Search is smart enough to know that content that is nine nested folders deep is not as relevant as something that is at the root. That piece of content will end up on page 47 of your search results.
Set up the folder structure, then turn off the ability to add folders. Lock the into that structure so you don’t have the folder sprawl that plagues your shared drives. Then, create all of the views based on metadata and remove the folders from the views except for the view for those putting files in there. You can link to that particular view off the Quick Launch and limit who sees it by audiencing the link.
I’d be certain to invest the energy in creating good content types. You might want the PM’s name for all project plans, but you wouldn’t need it for the office picnic flyer.
Don’t just use one big library. Each library should have like content, not the same content types but similar content. You will end up with libraries that use workflows and libraries with more static content. The main the reasons why you split up your content into more than one library is because the content is very different from the other content, permissions vary, and the use of workflows for approvals and such. Unless a workflow is breaking permission inheritance, don’t break permissions inside of the library. It becomes much uglier to manage and can easily lead to orphaned content.