Over a period of almost 10 years of providing support for SharePoint (2010, 2013, Online), one of my key learnings has been to avoid complexity in its implementation. The more complicated the implementation is, the harder it will be to support, fix and maintain.
This post contains several tips for implementing SharePoint to minimise complexity and therefore the need for support.
Before the tips, it is important to understand the original SharePoint architecture model as this model (a) likely continues to exist in many organisations and (b) can influence decisions – not necessarily in a positive way – about how to implement SharePoint Online.
Understand the (historic) dual nature of SharePoint
SharePoint was first released in 2001. There continues to be a lot of legacy SharePoint implementations and approaches to SharePoint Online that reflect these older implementation models.
SharePoint has always had two sides – the publishing functionality (usually in the form of an intranet) and the document management functionality (where documents are stored). Sometimes these two are conflated into the single term – ‘intranet’ when in fact they are two quite different things in terms of architecture and usage.
Older (pre Online) on-premise versions of SharePoint typically consisted of multiple web applications in several app pools, as the diagram below shows.
Within each of these web applications, organisations would have one or more site collections, often with sub-sites. Almost none of this architecture model remains in SharePoint Online – there are now only sites, which are still technically site collections, but preferably without any subsites – see below. This is sometimes described as a ‘flat’ implementation as every site (formerly a site collection) is on the same ‘level’.
The publishing functionality, enabled through the publishing features, was typically used for intranets. Most information was presented on pages, typically across multiple subsites, with some use of the document libraries (e.g., to store common forms or policies).
But the publishing User Interface (UI) was poor; most organisations engaged a third-party to create more engaging (and usually heavily customised) intranets. The outcome has often been that organisations have had to maintain old legacy SharePoint servers to keep the ‘old’ intranet running. In most cases, these older SharePoint sites cannot be migrated ‘as is’ to SharePoint Online.
The former publishing functionality was replaced in SharePoint Online with communication sites.
The document management functionality was (and continues to remain) the default ‘out of the box’ (OOTB) option for all new team sites. Most older SharePoint sites had to be accessed via a browser and the older UI was often seen as not very interesting or engaging. Business areas would sometimes customise the site pages, sometimes to the point of making them appear to be ‘local’ (business area) intranets.
Although SharePoint Online has the same dual nature, it does not use web applications. Instead, all site templates (communication or team) must be created under one of two paths: /sites/ and /teams/. Organisations may default to just one of these two paths for all sites, or could decide to make use of them to differentiate between, e.g., enterprise sites (cross organisational, e.g., the intranet) and team sites (the name of the business area/team comes after /teams/).
Tip 1 – Try to avoid or minimise customisation
As noted above, customisation was common in on-premise versions of SharePoint. Microsoft have done a lot to improve the UI for both communication and team sites.
Microsoft have released a range of pre-canned templates for communication sites that can be downloaded from the ‘lookbook‘ site. (These templates will soon be available as a choice when new sites are created as well.) These templates and new web parts allow organisations to set up a nice-looking and engaging intranet, with no customisation, (other than via the web parts on each page), that is easy to support and manage.
Organisations that require more complex intranets can of course continue to customise their communication sites and/or use a wide range of third-party tools. These are likely to require a higher level of support to maintain and troubleshoot issues, including from third-party vendors.
The customisation of SharePoint team sites used primarily to store and manage document-type content (e.g., to replace network file share storage) is now a different matter. The rapid adoption of MS Teams as the primary UI to access this content over the past 18 months and the ability to sync document libraries to File Explorer and access the content on a mobile device, has in most cases made browser-based access redundant.
There is no longer much point in customising the browser (pages) view of SharePoint team sites used to store documents. Customisation in these sites is more likely to take the form of the site structure, content types and columns, permissions, or the types of information stored in them. Any customisation of team site pages should be restricted to the out of the box options.
Tip 2 – Don’t overcomplicate the structure
Older versions of SharePoint could have quite complicated structures – from the web application through to the site collection, sub-sites, libraries, content types and columns.
These structures would inevitably cause issues over time as organisations re-structured or were renamed, or wanted content moved to different parts of a site or a different site. The easiest sites to manage were always the simple stand-alone sites which is, fortunately, the preferred model in SharePoint Online.
To avoid complexity with all SharePoint Online sites, don’t create sub-sites unless absolutely necessary. Microsoft don’t recommend sub-sites any more – see ‘Planning Your SharePoint Hub sites‘. To quote from that page:
Subsites don’t give any room for flexibility and change. Since subsites are a physical construct reflected in the URL for content, if you reorganize your business relationships, you break all the intranet relationships in your content. Subsites can also create challenges when it comes to governance because many features (including policy features like retention and classification) in SharePoint apply to all sites within the site collection, whether you want them to or not. This means that you must frequently enable a feature for the entire site collection, even if it’s only applicable to one subsite.
Instead of using sub-sites in communication sites, create multiple pages linked via the out of the box mega menu or links.
Avoid using sub-sites at all for team sites unless there is a genuine requirement to restrict access to part of the site. The same outcome can usually be achieved by changing access controls on a document library.
Tip 3 – Use Content Types and columns selectively
SharePoint is built on content types, including the common ‘item’, ‘document’ and ‘folder’ types. Older SharePoint implementation models sometimes made extensive use of Content Types and site (or library) columns to define content added to document libraries. This meant that end-users would have to select a Content Type and/or add or choose metadata when content was saved, a process that was seen as off-putting for most.
To minimise complexity, deploy custom Content Types and additional site or library columns only where really necessary, not as a default approach. Don’t use Content Types to differentiate between (ironically) content or document types but consider using site or library choice columns with default values instead. For example, if a document library is used to store records about meetings or committees, a drop down choice value for ‘document type’ is more likely to be used (and useful) than Content Types.
Tip 4 – Avoid complex permissions
Possibly up to 70% of all support queries over a decade related to permissions or access restrictions relating to a team site and usually started with ‘Why can’t I access …?’ or ‘Why can (so and so) see (or not see) this content?’ They rarely related to permissions on a publishing or communication site, which tend to have simple permission structures.
Almost all of the queries about team site permissions could be tracked back to someone changing the default inherited permissions. In one case, on a site with very complex permissions, a site owner deleted the site owners permission group, locking them out not only of the site but on every single part of the site that had unique permissions. It took a couple of weeks to restore these permissions.
Try to avoid changing the way permission inheritance works. The permissions set at the site level (example shown below) flow down to all the content. It is all too easy to lose sight of (and then find) what permissions have been changed.
If there is a genuine requirement to restrict access, consider moving that specific content to a separate library or even a separate site, rather than restricting access on items within a library, especially one that has a complex folder-based structure.
Also, keep in mind that over the past decade, the access model for SharePoint content has changed from (a) restrict access everywhere and only grant access to those who can access it, to (b) open access everywhere and only restrict access to what needs to be restricted. This is a much easier model to support.
The easiest way to give ‘everyone’ internally access to all SharePoint content is to add ‘Everyone except external users’ to the Visitors group of every SharePoint site, including sites linked with MS Teams. This access does NOT give them access to the Team channel posts in MS Teams.
Whether or not external users should be allowed access via external sharing will depend on each organisation, but it is a good way to reduce the volume of duplication that happens when content is attached to emails. It can also be monitored.
Avoiding access control complexity should also help to improve information security, by ensuring that controls are more easily understood.
Tip 5 – Avoid storing too much and/or unrelated content together
SharePoint sites (including those linked with Teams) are a form of logical aggregation or container. And you can store a LOT of content on those sites. According to the Microsoft site ‘SharePoint Online limits‘:
A library can have up to 30 million files and folders. When a list, library, or folder contains more than 100,000 items, you can’t break permissions inheritance on the list, library, or folder.
But, as the saying goes, just because you can doesn’t mean you should.
It is all too easy to see the ‘Documents’ library of every SharePoint site (especially Teams-linked sites) as the equivalent of a top level folder in a network file share with multiple folder hierarchies. This might seen quite appealing and simple to use at first, but after several years, the ‘Documents’ library can end up a lot of content, not all of which is related to the site’s original intended purpose.
After 10 years, the content is likely to resemble an uncontrolled network file share, with redundant, trivial and outdated content all over the place. With potentially up to 30 million items, this will make managing the content so much harder.
As much as possible, try to ensure that SharePoint sites are based on logical business functions and the libraries in those sites mapped to business activities.
This is not always easy; for example, many smaller organisations have a ‘corporate services’ type function that includes a range of business activities, including managing property, general admin, legal, HR/personnel, fleet and corporate meetings etc. While all of this content could be stored in a single SharePoint site, there is likely to be a requirement to restrict access to content (see previous point) which will only result in increasingly complex permission controls and support issues over time. Mixing unrelated content could also become a nightmare for compliance and records management.
A better, more sustainable, option would be to create multiple SharePoint sites (or Teams) with multiple libraries, linked via a hub site as necessary. This approach will also make it easier to manage records in the longer-term.
Feature image – original source unknown
Records about the world 
You said “For example, if a document library is used to store records about meetings or committees, a drop down choice value for ‘document type’ is more likely to be used (and useful) than Content Types.”
Content Types primarily serve the purpose of determining which metadata columns are included in a library and which columns are populated for a given item. They are useful for deploying groups of site columns across a large enterprise. A single column with a document type doesn’t meet those requirements.
Thanks for your comment. The sentence starting with ‘For example …’ comes in the tip about reducing complexity. I don’t say NOT to use Content Types, just to use them (either globally or at a site level) where they will provide most value. There will almost always be a case for a ‘local’ set of terms and Microsoft make it easy to create these now via the Library view.