Understanding how a flat SharePoint architecture operates is critical for discerning the potential follow-on effects when applying Purview Retention, Information Protection, Data Loss Prevention, and Insider Risk Management controls.
What is a “Flat SharePoint Architecture”?
In a flat SharePoint Architecture, when a new SharePoint location is required, a separate site is provisioned rather than a subsite within a parent site. A flat architecture is recommended by Microsoft and is adhered to in Microsoft 365 anywhere a site is provisioned. The options below each create a separate site to hold file content:
- Create a site in the SharePoint App
- Create a Team in Microsoft Teams
- Add a Shared Channel in Microsoft Teams
- Add a Private Channel in Microsoft Teams
- Create a community in Viva Engage
- New Group in Outlook
- New Plan in Planner (if you choose NOT to add to an existing Microsoft 365 Group)
Isolating each site provides benefits by creating boundaries for storage quota, branding, site membership, permissions, search, information architecture, and Purview controls. If organizations are using the above options for provisioning sites, a flat architecture will be automatically achieved. In contrast to the flat architecture described above, a common architectural model used in years past in SharePoint Server was one where nested subsites were created within the parent site instead. Although this model had some advantages at the time such as shared navigation, branding, permission inheritance, and a built-in hierarchy, the disadvantages I’m covering in this post for storage quota and Purview controls now outweigh any advantages subsites once might have provided.
I still see subsites created today in SharePoint Online for a few reasons, the most common one being the result of a “lift and shift” migration from SharePoint on-premises, where subsites were in use, to SharePoint Online. I also see custom solutions that create subsites programmatically due to some of the subsite advantages listed above.
Unfortunately, the ability to create subsites is enabled by default in a tenant which, left unchecked, allows any site owner to also create one through the UI (Site settings… Site Contents… Subsites tab… New… Subsite).
My recommendation is to disable the creation of subsites through the UI, particularly if you plan on also enabling some of the Purview features discussed in this post.
To disable subsite creation, navigate to the classic SharePoint Admin Center (https://<domain>-admin.sharepoint.com/_layouts/15/online/TenantSettings.aspx) and check the Disable subsite creation for all sites radio button as seen below in Figure 1.
Although reasons exist outside of Purviewon why it is advantageous to maintain a flat architecture, this post focuses on why the flat architecture model is important to Microsoft Purview and highlights some implications if you don’t. The two Finance division sample architectures in Figure 2 will be referenced for examples.
The Storage Impact of the Preservation Hold Library (PHL)
Microsoft Purview uses a hidden library called the Preservation Hold Library (PHL) for sites (and subsites if you have them) to preserve content. Mostly, the PHL is a black box you need not concern yourself with since it is automatically provisioned for a site only when required, and content is added to and deleted from the PHL by the Purview back-end service.
The PHL impacts storage for your SharePoint environment since the space it consumes is part of the overall storage quota allotted for each site (inclusive of all subsite PHLs). Compounding this, you cannot delete content from the library since it is controlled by Purview.
It is therefore important to understand which Purview controls add storage to the PHL:
| Purview control configured | What it stores in the PHL |
| A retention policy published to the SharePoint site. | A copy of any file change/deletion is preserved in the PHL for the retention period set by a retention policy. |
| Unlocking a file with a record retention label applied to preserve the previous record version. | A copy of the record before changes are made to it is preserved in the PHL. |
| The Records management setting allowing users to delete labeled items on SharePoint sites. | A copy of the deleted file is preserved in the PHL. (in addition to going into the recycle bin) |
| An eDiscovery hold placed on a SharePoint site. | Like a retention policy, a copy of any file change/deletion is preserved in the PHL for the duration of the hold. |
| Preservation of cloud attachments for later discovery by eDiscovery Premium (Preview). | A copy of the exact file version shared as the cloud attachment is preserved in the PHL. |
| Adaptive Protection (Preview) preserving a copy of unlabeled file deletions for any elevated risk user. | A copy of the deleted file by an elevated risk user is preserved in the PHL. (as of July 2024, it is preserved for 120 days and then deleted) |
Careful consideration of your SharePoint architecture and understanding which of the above Purview controls are in use today is part of an important storage planning exercise.
Finance Division example: in the subsite architecture, the space consumed by all the subsites’ PHLs combined will place an increased demand on the Finance Division site’s storage quota.
Applying Purview Retention Controls
Whether you’re using a retention policy to retain/delete content on a site, a label publishing policy to publish a standard set of retention labels to a site, or an auto-apply label policy to apply a retention label to items within a site, the most granular location you can scope it to is a site… not a subsite. Everything in a site, including all subsites if you have them, will be targeted. Site adaptive scopes can be built to dynamically include/exclude sites for retention but cannot be scoped to a subsite.
Finance Division example: if you needed to apply a 2-year retention policy on the Partners subsite and a 7-year retention policy on the Budgets subsite, you couldn’t do this. You could only publish a retention policy on the Finance Division (parent) site which would apply the same retention settings to it and all its subsites. You could, however, apply different retention policies across a flat architecture model.
For this reason, maintaining a flat architecture provides you with the most flexibility and granularity for targeting different retention controls across SharePoint.
Applying Purview Information Protection Controls
Using sensitivity labels to safeguard content in containers (Microsoft Teams, Microsoft 365 groups, and sites) can control things like site privacy, guest access, external sharing, unmanaged device access, and authentication contexts. The controls enforced by the sensitivity label work across a flat SharePoint architecture since they apply to the container in its entirety and cannot differentiate one subsite from another within the parent site.
Finance Division example: if you wanted to allow Guest access on the Partners subsite, but NOT allow it on all other subsites in the Finance Division, you couldn’t do this. A flat architecture model would allow this.
For this reason, a flat architecture provides you with the most flexibility and granularity for targeting container-scoped information protection controls that may differ across sites.
Applying Data Loss Prevention (DLP) Controls
Like retention and information protection controls, from a SharePoint perspective, the locations you can target for a Purview DLP policy can only target sites and not subsites.
Finance Division example: if you wanted to block access for external users on files uploaded with sensitive information to the Partners subsite, but NOT block it on other subsites in the Finance Division, you couldn’t do this. A flat architecture model would allow this.
For this reason, a flat architecture provides the most flexibility and granularity for targeting specific DLP policy conditions and actions across SharePoint.
Insider Risk Management Settings
If you have some sites that are more sensitive than others, you may want to identify them as priority locations in Insider Risk Management, so they are assigned a higher risk score. Priority location(s) you specify can only target sites and not subsites.
Finance Division example: if you wanted to identify only the Budgets and Reporting subsites as sensitive so they could be assigned a higher risk score, you couldn’t do this. A flat architecture model would allow for this.
The reverse of this is also true – you may have some sites that don’t contain sensitive information and that are frequently shared with external parties. You may want to exclude these types of SharePoint sites so they will be ignored and won’t generate alerts for your policies.
Finance Division example: if you wanted to exclude the Partners subsite from insider risk policies because you routinely share non-sensitive content to partners externally from there, but include all other Finance Division subsites, you couldn’t do this. A flat architecture model would allow for this.
Flat Architecture is Best for Purview
When planning Purview controls, a flat SharePoint architecture offers the most implementation flexibility. If your current architecture is not flat, consider restructuring it to a flat design to effectively utilize these Purview controls.
