SharePoint: Subsite or page?

Many things can undo your SharePoint environment.

• Subsite templates that are too locked down
• Layers and layers of folders in document libraries
• Site sprawl.

That last one strikes fear in the hearts of system administrators and support specialists who are tasked with maintaining the entire SharePoint environment. Although SharePoint was intended to be managed at the subsite level by administrators from operational areas of an organization, without a bit of understanding of the architecture, things can get ugly, fast!

Because we like to arrange things hierarchically (think folders, sub-folders, sub-sub-folders), we have a tendency to think of SharePoint subsites in the same way. However, there is one very important difference to traditional hierarchies and SharePoint hierarchies. A folder hierarchy implies that you have access permissions at the higher levels of the structure, for example the Accounting folder, but not at lower levels, perhaps, like Payroll. When fully expanded, you can examine the entire structure and contents of the hierarchy.

In SharePoint each subsite is its own universe, with its own content and potentially its own permission structure. A site at a lower level in the hierarchy does not “see” the content at higher levels simply because it was created “under” it.

A general rule to follow when it comes to creating subsites is this: If the access permissions are different, then create a subsite. Otherwise, create a page. So, for example, if everyone in accounting has access permission to see the payroll content, but only a few work with it regularly, you might consider creating a payroll page on which the payroll folks will find everything they need to do their jobs. And, while the payroll content may not appear on any other pages on the site, anyone with access permissions will be able to navigate to Site Contents and see that it’s there.

Another approach is to apply permissions to the individual list or library. So, for example if there is one list or library to which access should be restricted, you may apply restricted permissions to just that object. Even if you have access to everything else on the site, you won’t even see that particular list or library on any page, or even in Site Contents. Managing at this level should be the exception rather than the rule. Access permission structures should be well planned to ensure that managing them doesn’t become a full-time job, or worse, a house of cards. When access permission structures get too complex, inappropriate access permissions may be too easily granted by mistake.

To stay on the right side of site sprawl, require multiple approvals, at least administratively, before creating additional sites. You may also disallow the ability to create subsites for subsite administrators. To do this, remove “Manage Hierarchy” privilege and allow “Design” instead. Subsite administrators will be able to create lists, libraries, and pages, but not subsites. Regularly audit permissions on your site by visiting Site Settings and clicking on Site Permissions. Click the Check Permissions button to test access for select individuals to see how they are granted access and what level of access is allowed.

Remember that the goal of SharePoint is collaboration and controlled sharing of content. Organizing content into a hierarchy of folders or subsites might appear controlled and navigable, but it may not be in practice. Build good site development guidelines into your governance procedures and processes. When new subsites are built to address an access permissions issue, test both the ability to get to the content and the prevention of that access by an unauthorized user.