SharePoint Content Management: Distributed vs. Centralized

In modern SharePoint, we have content management tools which have been honed over decades of SharePoint use. At the same time, our ideas about content management have evolved over that time. People are far more comfortable maintaining content on the Web than they were when SharePoint first was released. Back then, we were often transitioning from a printed content mindset, so many organizations simply tried to apply the same sort of processes and logic to Web content that they had been using with physical content for the prior decades. This often led to quite convoluted “requirements” in order to support that traditional way of thinking about content management.

These days most people are very comfortable with the Web. For many people in the workplace now, it’s the only thing they have known. Binders like this on bookshelves above desks would be an anathema to most of them.

So, cutting to today, we can instantiate simpler content management rules, and we can also rethink content ownership.

Centralized Content Management

In a centralized content management scenario, a particular content type – and you should think about this on a content type level – is fully managed by a central group of people. Some examples might include:

• All Policies are managed by the Human Resources department
• Operations is the only department which can issue a Standard Operating Procedure
• Any Standard having to do with money or timekeeping must be written by Finance

These are perfectly legitimate scenarios. However, they require a “pinch point” in that anyone in the organization who wants to issue a policy, for example, must work with Human Resources to create and publish it. It puts the policy content management egg into one basket.

In many cases, centralized content management has been the norm for many years. Some of this harks back to the print-to-Web transition and some of it harks back to the ways SharePoint and the Web worked in their earlier days.

Distributed Content Management

In a distributed content management scenario, we allow the people who understand the content best to manage it where they manage the rest of their content. Some common scenarios include:

• All departments can publish Policies based on their operational oversight
• Standard Operating Procedures are certainly published by Operations, but other departments can also publish them, as needed
• While Finance controls all financial Standards, other groups can publish them as well

For this distributed publishing to work well, we need several things in place:

• Each group (usually departments, but it can vary based on the Content Type) creates and vets the content in their own Team Site.
• Team Site Owners can publish content from their Team Site to their Intranet site, simply using Copy to or, if a more rigid process is required, with that process implemented with appropriate tools.
• Each site where a specific business object will be published has the proper information architecture (Site Columns, Content Types, Document Libraries) for that business object instantiated in it.
• The metadata used in each Content Type should provide enough information – and not much more – that’s required to display the content in several different ways:
  • In a “content center” for that Content Type or family of Content Types
  • In search-driven experiences embedded in specific pages
  • Natively in the Document Library where the content is actually stored

Distributed Publishing Example

When we work with clients, we almost always use the example of Policies to illustrate distributed publishing. Policies are a common business object which is well-understood by most people in an organization. Some organizations have many policies, some have just a few. In most cases, each department has its own set of policies which it has created.

We choose a site to use as the starting point. Usually, it’s the first group which has said they need to post Policies. n almost all cases, we first create a “base document” content type – something like Base ClientName Document. All the custom Content Types we create for the organization inherit directly or indirectly from this Base ClientName Document Content Type. In that site, we create a Content Type called Policy, which either inherits from Base ClientName Document or another parent Content Type that makes sense for hierarchy.

For a Policy, the metadata may vary from organization to organization, but we usually hove some columns like:

• Effective Date
• Expiration Date
• Applies To (maybe a set of geographies or departments)

Next, we create a Document Library called Policies and enable the Policy Content Type in it, removing the default Document Content Type. We create a Policy in the Policies library – singular and plural. At this point, there’s usually a little iteration on the metadata, etc. This is a good pause to take, so we can be sure we understand how best to construct Policy to serve its purposes.

Now that we have a Content Type and it is enabled in a library, we turn to PnP.PowerShell. With PowerShell, we can export the definition on the library as a Site Script unisng Get-PnPSiteScriptFromList, like so:

Get-PnPSiteScriptFromList -Url $fullPath | Out-File "./ListName.json"

where $fullPath is the full URL to the list, like “https://contoso.sharepoint.com/sites/teamsite/lists/MyList”. Note that PnP.PowerShell doesn’t care if we’re working with a list or library: under the covers, they are basically the same thing.

This gives us a JSON file which can be instantiated as a Site Script using Add-PnPSiteScript. Then we can bundle that one Site Script into a Site Template (nee Site Design) or include additional Site Scripts if we want with Add-PnPSiteDesign. I’m going to gloss over this a little bit and come back to it in a future post.

Now we have a Site Template we can apply to any site where we want to store Policies. Even if I’m going to include the Site Script in larger Site Templates, I may set up this simple Site Template to just instantiate the Policies library. I like the atomic approach to this.

When we choose to apply this Site Template to a site, we get the Policy Content Type (defined consistently, so to SharePoint it’s the same Content Type in each site) and a Policies library with it enabled.

Now each group of people with a site can create a Policy in their library – following their processes – and we can roll all the Policies up across the tenant or across sites associated with a Hub Site very easily. Most of the time this means a custom page built using the PnP Modern Search Web Parts (just about my favorite Web Parts!). We often call this something like the Policy Center.

End users can find a Policy where it’s published, perhaps by navigating into the HR site, or go to the Policy Center page we created above. We can also expose specific sets of Policies – maybe Policies which will expire in the next month – in experiences to help with central oversight.

If you’re thinking that this is a lot of work, it really isn’t. I do it all the time – with many more Content Types in each tenant in which I work – and this whole process can be as little as a few hours of effort. Compare that to the dreadful user experience you might have if you’re just dumping Policies into libraries as a Document Content Type, wherever you might choose. And believe me, it’s more work to clean all this up after you have a lot of content in SharePoint than it is up front, or at least early on.

Also note that starting at this level doesn’t mean you can’t layer more complex processes on top later. In fact, it makes it far easier when you get to that point; everything is neatly assorted so a Policy is a Policy is a Policy.

---

Taking this approach is also one important part of moving up the maturity model for Microsoft 365. Check out the Maturity Model for Microsoft 365 – Management of Content Competency in the Microsoft 365 Community Docs.