I've been tasked with transitioning a document control system into Sharepoint. We have a custom solution (that is, incidentally, on a platform that is no longer supported) and I'm having difficulty determining how I should approach imitating it in Sharepoint. (We've selected Sharepoint because we already have a license for it in our Organization.)

What we currently have is a really nested folder structure. Down four or 5 levels, for example:


By default, the folders are all not expanded, so it takes up little space. Everyone is used to how it is organized and are able to find anything they are looking for quickly. Files can be added quickly by clicking on the folder you want to add the file to, which brings up a window that lets you select the file you want to upload.

I've been reading that in Sharepoint, it is usually better to not have a hierarchy like this and rather to just classify documents with columns in their stead. The problem with this solution is two fold:

1) I'm not allowed to deviate from the hierarchy that exists as it would require a multi-month long bureaucratic process requiring a lot of people to agree on what it should look like before it can be built.

2) I cannot figure out how on earth I would get Sharepoint to come up with anything that remotely resembles this. I've tried Document libraries, but obviously MS doesn't want people using folders for this type of thing. Having a multi-second delay to get into the file and having it completely change the windows is an unacceptable solution. Similarly, if I were to use metadata, it seems like I would need to have either 100 columns or use one column per level of hierarchy. The former is obviously too complicated and the latter would group files together that have no relationship. (For example, a sub folder being grouped with an unrelated parent folder).

Too much deviation from this is going to be an impractical solution and I fear would be too simple for files to get lost.

Is there a way to replicate something similar to the picture above? Or am I stuck trying to convince people to switch the hierarchy they've used for 15 years?


Sometimes the best practice isn't practical and trying to deviate away from what you are accustom to brings about inefficiency. The general guidance is to not use folders, but there are benefits of using them that people gloss over or dismiss as part of their utopian no folder libraries.

Document libraries have limitations, like list view thresh holds, using folders helps alleviate these pressures. Folders are securable objects that can be different than the document library. In a large library, this can be cumbersome to manage, but it is a benefit of folders, it is mucheasier than item level permissions.

You can do what you have laid out. This is totally supportable.

What you may run into is URL character limitations. If the folders have long names and are nested deeply, you can hit the 256 URL limitations.

There is a feature in the document libraries that allows you to automatically tag documents with metadata when they are uploaded. This is called Column default values in the document library settings. Here you can tag folders to apply specific metadata to files when added to it.

This would allow you to transition to a metadata driven library over time as people become accustom to the new system.

  • That's what I was afraid of. These ones are definitely going to run into 256 character limitations. One of the folders alone is 300 characters long for... reasons. Guess I'll have to try to either convince them to truncate the names or go with a new solution. Thanks for the feedback! – mkingsbu Jan 17 '17 at 16:19
  • Something else I've done is to flatten it one level by putting all the root level folders (Level 1 in your pick) as their own document libraries, level 2 then becomes the new root level folder. It can help shave off some characters. – Eric Alexander Jan 17 '17 at 16:25
  • I was thinking something similar. I'm not sure if they need to be able to search all of the documents in the library, or just ones in - for example - level 2. (Or even more fine grained). Hopefully just the latter since that would be a lot easier to implement from what it seems like. – mkingsbu Jan 17 '17 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.