UPDATE late December 2022: Since this post was published, Microsoft has changed the way SharePoint subsites are created. The default setting for newly created team sites is that subsite creation is disabled for end users. Accordingly, we have decided to remove subsite support from the SProbot structure designer to ensure that whatever we build follows the path of least resistance and most future support. We like the principle of "strong opinions, loosely held", which is why we changed our minds on this only when it became impractical.
The original article content:
Is a flat topology necessarily always better?
More specifically, you're here because you want to know: Should I use SharePoint subsites? Also, SharePoint site vs site collection?
Since SharePoint Online (and more specifically hub site functionality) was launched, Microsoft has been recommending that a flat topology is best, with detailed explanations of the challenges presented by classical top-down topologies.
This has resulted in many consultants and MVPs arguing that no one should ever create subsites.
This is silly. Most requirements are unique, and our team at BSOLVE still recommends hierarchical SharePoint structures with subsites when it's logically necessary.
One of the most commonly cited reasons for not using nested subsites is that it results in complex permissions. For a large percentage of the SharePoint content generated via modern sites (specifically sites linked to Teams) this is a valid concern. Self-service Teams creation sees the average organization generating a hefty number of content containers on an ongoing basis, and anything other than a uniform and flat permission structure has the potential to cause significant support and admin overhead when the owners of these sites aren't permission-savvy.
This kind of unstructured, dynamic and often-temporary content makes it necessary to delegate permission management to each site's owners, and a simple "these are the people who can edit everything in this container" in the form of the M365 group membership panel is what most new content owners have become used to. This is great!
But...
Not all SharePoint content is decentralized, unstructured or fleeting. In fact, a fair portion of the "single version of the truth" content within most organizations needs more hierarchy and granular permission management than what can be offered by a flat site collection approach.
Hierarchical structures with subsites make sense in scenarios where:
- The various portions of structured content at the same level (and even surfaced on the same page) are maintained by different people or groups of people, not just by a single group.
- Content (both files and pages) needs to be made available in read-only format to some users and edited by others.
- There is a formal content publishing process.
- There is a logical flow of increasing access control as you drill deeper into the structure for certain subsets of information.
- It's useful for the URL to serve as a logical indicator of where in the hierarchy you are, and for a single "base" URL to indicate what primary grouping of content you're accessing, rather than just hub site navigation.
Basically, all scenarios where a logical hierarchy is in play, still benefit from subsites. Guess what: There are still plenty of these scenarios!
For example, it's useful to have a tightly defined hierarchical structure for formal containers such as project or client sites, where each needs a standard set of functional compartments which different groups within the business can access, rolled into a single site collection to get all the benefits of collection management. This is especially important when some of these groups should not be accessing each other's content even though they're working on the same client.
OK, so SharePoint subsites are useful after all? They are, but there are some caveats:
- Going more than 2 or 3 levels deep starts creating navigation confusion for users, so it's best to be conservative with this.
- Permission management in these structures is best left to power users. Limit ownership of these sites to skilled administrators only, or make it a policy to simply not change permissions after initial creation.
- These sites should be provisioned in a standardized, fool-proof way which ensures that permissions are correctly configured each time. SProbot provides the ideal tooling to accomplish this.
For many of the scenarios out there, a flat topology does make sense. This includes:
- Teams, where all content is collaborative, and everyone should be able to change everything.
- Ad hoc project or initiative sites where there is no formal definition of access or structure.
- Content which is likely to move or be reorganized within the foreseeable future (no one has a crystal ball, but this is sometimes clear).
- Content which does not have formal ownership and where it may not be possible to formally define the publishing process.
