How do you decide on the structure of your SharePoint environment? In this blog I’ll talk about how to structure your SharePoint environment to make it easy to apply policies for sharing, retention and content sensitivity. I will focus on SharePoint Modern Team sites in this post, although some of this also applies to Modern Communication sites.

The basic building blocks of SharePoint from a content perspective are Sites, Lists and Libraries. I think of a Site as a container for content (Lists and Libraries) that can have security and policies applied. Microsoft Teams also uses a SharePoint site for file storage. A SharePoint ‘Team’ site can be created either with or without a Microsoft Team.

Architecturally SharePoint is designed to have multiple Sites rather than one site containing all of your content, unless you are in a very small organisation. Grouping related content together is a good idea to make it easy to distinguish different content and find what you’re looking for. For example, create different Sites for Marketing, Policies, Health and Safety, Finance and Projects (a Site per project is often a good idea).

Hub Sites provide a way of grouping related sites, sharing navigation and search scopes. You may have a need for multiple Hub sites. In this example I have seperate Hubs for Intranet functionality vs collaborative sites. You may have more Hubs to cater for you specific needs. Note also that not all sites need to be associated with a Hub.

To determine the sites you need asking some questions to identify the groupings, permissions needed, security and compliance requirements:

• Who owns the content in the site?
• Who updates the content in the site?
• Who reads the content in the site?
• Who shouldn’t see the content in the site?
• Can this content be shared outside the organisation?
• Will external users (Guests) need access?
• Is this content sensitive?
• Is there a requirement to apply a retention policy to this content?
• Does all of the content in this site belong together?

Microsoft policies for Sharing, Retention and Sensitivity Labels are all applied at the Site Level. If you require different policies then split the content between sites. For example, Human Resource content may have conflicting requirements where some is sensitive and Human Resource access only e.g. employee records, while other content such as policies, templates, general employee information may need Read access to all. Implementing these requirements in a single Site is complex, but splitting the content between two Sites makes it much easier. The employee facing site can be a Public Group while the Human Resources only content remains a Private Group.

Project content is another area where you may have different permission requirements. When you invite Guests to join a Microsoft Team, they get access to the SharePoint Site associated with the Team. Having a Site (or Microsoft Team) per project means you can limit the Guests to seeing just the content related to the project they are involved in and another project can have different Guests. It also makes it easy to revoke access once the project is complete and the Guests no longer need access.

Applications like Dynamics 365 and SAPcan use SharePoint as a document repository. Keeping that content in it’s own site is good idea as it makes it easy to understand the integration and apply appropriate security and governance. You may also find these sites store a large volume of content due to the way they CRM and ERP systems tend to structure data in folders within a library or group of libraries. You should also consider the storage limits within SharePoint, especially when architecting for large volumes of content.

Sharing policies control whether the content contained in a Site can be shared externally, which domains it can be shared with, if anonymous links can be used and the default sharing link type.

It is common to have different requirements for both Retention and Sensitivity Labels based on the type of content stored in a site. Site structure should take this into account, for example finance content with a seven year retention requirement, may have a different requirement to quality content or Board related content.

It is possible to have more granular permission control at the List or Library level within a Site. This adds complexity to permission management but is a necessity in some use cases. Active Directory groups can be used to manage the permissions.

Each Site can be associated with a Hub Site to share global navigation, branding and search scope. You can learn more about this in my post on Hub sites.