Anyone who’s worked on a Windows machine in the last 30 years will find the image below familiar. It shows a file share containing reporting documents organized by year and department. 

Sounds easy, until you realize that the department folders are inconsistently named and some of them change from year to year. Nested folders are easy to create, but also easy to abuse and difficult to navigate and manage.

Such document library problems – and the bad habits that create them – can carry over into SharePoint. It’s tempting to pull this structure into SharePoint document libraries directly but that doesn’t solve the problem. Similarly, it’s tempting to create endless subsites in the same way that user create nested folders.

Resist the temptation to misuse sub-sites in SharePoint. Read on for analysis of the problem and for more efficient ways to structure site content.

 

The Problem with Nested Folders

Nested folders tend to create confusing structures that are difficult to use and manage. In the example above, of performance reports for each fiscal year, the structure changes from year to year and no naming protocol for folders exists. SharePoint makes it too easy to import documents in the same nested structure we’ve used for decades for file shares. So we just do it.

Don’t.

SharePoint offers much better tools for users to access and interact with documents.

 

 

Instead of perpetuating this nested folder structure, flatten the data into a single view. That is, all the documents should be at the same level. Then create columns for fields, such as Year or Department, and “tag” data with the appropriate fields. Under this regimen, users will be able to filter by year or department instead of searching through folders to find the documents they seek.

 

The Problem with Nested Sites

In essence, site structure in SharePoint mirrors a nested folder structure. You typically have one root site that becomes the main site, and department sites live under the root site. Many organizations misuse or overuse nested sub-sites and make their data unmanageable.

 

  

 

The site contents view makes it easy for anyone to add a subsite when they really ought to just add a page, list, or document library to an existing site.

Consider setting a limit on levels of navigation in your SharePoint environment. You might even turn off the ability to add sub-sites.

 

Ways to Prevent Nested Information

All that being said, we understand that both document libraries and sub-sites can be useful. In principle, absolutely nothing is wrong with using them. But keep in mind that misusing their features can get you into trouble in maintaining content and site security in the long term.

 

Use Governance Policies

Have your governance team implement content publishing guidelines. A guidelines document provides a reference for use of certain features of SharePoint and disseminates rules on use of those features. It will serve your content managers well.

What sort of guidelines might your governance team include?

• Turn off the ability to add folders in SharePoint lists and document libraries. This can be done manually, at the list level, or scripted in PowerShell to turn this setting off in all existing lists/document libraries.

 

Turn off the ability to create folders in document library settings.

 

• Limit user permissions, so only content managers may add sub-sites to a site.
• Specify separate permissions for use cases in which a new sub-site is appropriate and for cases in which new content is better off as a page on the parent site.

 

Set Up a Framework for Managing Documents

Most companies that make the jump to SharePoint previously managed their documents in a messy file share like the one at the top of this story. Don’t import old problems to a new platform.

Instead of mimicking the folder structure of a file share, check out SharePoint’s document libraries features. They give you capabilities beyond that of a regular file. For example, versioning can be turned on or off in document library settings. You can also add columns to “tag” data with standard values; under the old regime, this data would reside in inconsistently-named folders. Filter for data; don’t hunt for it in a haystack of folders.