Why you should always govern SharePoint content types
Why govern Content Types?
In our recent webinar on managing large scale rollouts of Microsoft 365, especially those focusing on SharePoint and Teams, we discussed the pros and cons of governing your solution.
Proper governance, when executed well, is a sure-fire way to maximize the ROI of your investment in the platform.
One of the key aspects of SharePoint governance is the use of content types. Content types are the solution constructs we use to group metadata into meaningful sets. For example, we use metadata when we create an Invoice content type and capture the invoice amount, due date and vendor name.
The proper governing your content types will allow you to:
Maximize the reuse of your configuration
Ensure a consistent user experience across sites
Minimize maintenance
Improve the user experience
Improve user adoption
Streamline activities like eDiscovery and records management
Help integrate line of business solutions
Improve search and so on…
A brief history of content types
SharePoint does allow you to create local columns of metadata at the library level, but they’re not reusable in other lists or libraries nor other sites. So, if you spend an afternoon hunting down the org chart and typing out 50 departments in a drop-down list of departments as a local column, you’ll soon be frustrated to learn that you can’t reuse that list of departments elsewhere. You can probably imagine this list might be useful in other areas of SharePoint. In this model, It’s likely that other site owners will create their own lists’ of departments, perhaps with different naming conventions and spellings, perhaps using a different datatype (managed metadata, text, choice field etc.). Indeed we’ve seen implementations with dozens of different lists’ of departments throughout the solution which all need to be maintained and updated separately.
Lucky for us, the developers at Microsoft (or perhaps the original developers at VTI - Vermeer Technologies Incorporated) that thought up the idea of creating re-usable columns of metadata we call Site Columns – which if created in a site collection (now referred to as sites) would be reusable across the site. Hey great idea!
A similar design pattern for content types is Site Content Types.
The original design of SharePoint, I’m assuming, had assumed (is that too many assumptions?) that departments would seldom share information. Perhaps ironic given the name of the platform! So, when you created a content type in one site collection, it wouldn’t be available in other site collections by default.
One way to get around this was to define the content types via CAML – an XML based provisioning language which was about 100 times slower than hand configuring them, but allowed organizations to deploy content types across environments (development, test, and production) as well as across site collections through a cumbersome deployment process.
Introducing the Content Type Hub and content type publishing
In 2010, Microsoft introduced the Content Type Hub, a dedicated site collection that you chose to be the official source of Site Content Types (and their constituent site columns). These content types could optionally be published out by copying the definition to other site collections that subscribed to the Content Type Hub.
Once published, you patiently waited for a series of timer jobs to run. Or, you could run the timer jobs manually for faster deployment of content types if you were lucky enough to have access to Central Administration (SharePoint’s on-prem administration site).
Content Type Diagram, Copyright Microsoft ©
The Content Type Hub:
Made the reuse of content types and Site Columns across site collections much easier
Streamlined configuration
Allowed for a consistent user experience across site collections
Made it easier to share\migrate\move\archive content across site collections without losing metadata
Made records management easier (with products like Collabware CLM)
Made eDiscovery processes more streamlined
Allowed for easier creation of cross departmental search-based solutions. For example, creating a contracts portal that listed all contracts across the enterprise on one page regardless of where they lived.
Now it wasn’t all fun and games, as we did run the risk of:
Naming conflicts – when someone has made a content type or site column with the same name outside of the Content Type Hub process
Content type publishing failures – failures can happen if someone was changing the local copies of content types outside of the Content Type Hub
Scalability issues – once organizations got into the hundreds of content types it took a while for the content type publishing mechanism to copy all the definitions over, which slowed down development
By in large, managing these risks were worth the effort and overhead for the benefits of publishing content types. When properly governed, the issues above seldom happened and were easy to fix.
Content types in SharePoint Online
SharePoint Online (SPO) continues to use the notion of a Content Type Hub, though it’s a little harder to get to and has gone through a rebranding called the Content Type Gallery. Note: all sites have a Content Type Gallery so don’t get confused as to where you’re working. You can still get to the Content Type Hub by going to https://{yourcompanydomain}.sharepoint.com/sites/contenttypehub
Recently, SPO added the ability to add content types to a list or library that were published out from the Content Type Hub, without having to wait for the timer jobs in the back end (that we no longer have access to in the cloud). This further minimizes the overhead of leveraging what some feel is an ungoverned approach to SharePoint configuration.
SharePoint Online also allows management of content types through various automated means including:
PnP Provisioning
CSOM APIs
Site Scripts\Site Designs
Microsoft Graph API
You might use these in certain scenarios, say when constantly creating sites from a template (think project sites that need to get created on a regular basis). Even with these methods, it doesn’t mean we shouldn’t initially create those content types in the Content Type Hub.
Benefits of always standardizing on the Content Type Hub in SharePoint Online.
Maximizes the reuse of configuration
While it’s true that not every content type or site column will be needed everywhere, it can be hard to predict which sites will need them up front and always creating them in the content type hub will ensure that you can easily reuse them with little effort and no rework of your configuration.
Supports a flat information architecture
Gone are the days of sites with nested sub sites. Every site going forward should be a top level SharePoint site to minimize deep hierarchies of content, while allowing for organizations to easily restructure their SharePoint site through Hub Site Associations.
It’s likely that a given content type will be used across multiple sites that roll up to a single hub site for one department as well as allows for the reuse and standardization of content types across the enterprise.
Supports the movement and copying of files
It’s likely that you may want to move content from one site collection to another while keeping all the metadata in tact. This could be useful when archiving content, redesigning solutions for changing needs around security or scalability, managing Access to Information and Privacy (ATOP) or Freedom of Information Act and Privacy Act (FOIPA) requests (which often times require working copies of the files).
Simplifies design and minimizes rework
Most enterprise organizations will end up with 1000’s of sites. Some organizations create local content types when they think no one else will need those content types, and then create some content types in the Content Type Hub when they feel that they are more “enterprise worthy”.
This adds overhead to our design process. We recommend always going to the Content Type Hub to take out the guess work of where a given content type should live. We don’t need to stop and consider if a content type should be reusable across multiple sites, but rather we always know where to define the content type.
Simplifies Troubleshooting
If we know that every content type is defined in the Content Type Hub, it makes for easier troubleshooting content type configuration, minimizes the risk of naming conflicts and in the event where we guessed wrong, we don’t need to create duplicate content types nor do we need to painstakingly swap out content types through Power Shell scripts or move the content type definition into the Content Type Hub from another site.
Improves compliance
If we have standardized content types and Metadata across the enterprise, then activities like Records Management and eDiscovery will be easier to perform. These activities are now primarily search-driven and consistent and standardized configuration will allow organizations to manage records and perform eDiscovery across the enterprise more effectively.
Streamlines business processes and value-add solutions
Proper governance of content types will make creating search-based solutions like a Policies Portal that lists all policies across all sites in the organization via Search is easier to configure as you need to target only one content type for policies (and not the many possible permutations of policies that you could end up with if we weren’t governing them).
Standardized user experience
Creating a standardized user experience across the implementation will be easier since dealing with policies (for example) should be the same experience across all sites. So, when a user is visiting a site that they don’t normally work in, it should be easier to find there way around the site.
Arguments against centrally configuring content types
Delays in publishing
It used to be that we needed to wait for the content type publishing syndication process and unlike in an on-premises environment where we could run the timer job, sometimes we would have to wait hours for our content types to be made available, which could slowed down development when compared to the creation of local content types that were immediately available after configuration.
Counter Argument: This is no longer a problem given that once a content type is published, we can add it to the list or library immediately (without delay) in the new pull model that Microsoft has added to SharePoint online.
Scalability
It used to be that after creating several hundred content types were created, it could take a long time for the syndication process to copy out all of the content types required say when provisioning a new site collection and sometimes content types failed to publish properly if the timer jobs execution was interrupted (for example a server was rebooted).
Counter Argument: Since we get to target only those content types that we require, this is no longer an issue as not every content type gets added to the site.
Process overhead
It used to be required, especially in the on-premises environment that required you first to jump into the Content Type Hub and then into Central Admin (which sometimes required logging into a Server), to run timer jobs and then wait for those timer jobs to run. Then you faced potential troubleshooting issues if something didn’t publish properly. It was a bit of a pain, especially if you didn’t have the proper access and had to ask IT for help.
Counter Argument: Given the new design of Content Type publishing in SPO, most of the above issues are now gone and provided you have access and a bookmarked link to the central SPO Content Type Gallery, it should be a simple and seamless.
Governance overhead
Granted the governance of content types can still be a bit tricky as not everyone will have access to the Content Type Hub. Ideally Content Types are managed by a central team that will become experts in content type design and reuse. If you allow departments to design their own sites, then get them trained on using the centralized Content Type Gallery found in the SharePoint Admin center and avoiding local columns and to ensure that their changes do no affect other departments content. Creating content types is a skill, both and art and a science and it may not be fair to end users to expect them to become experts with this administrative function of SharePoint especially since the need to perform such actions is typically far and few between.
Counter Argument: While a centrally managed process does add a little overhead, the enterprise benefits over the long run will pay for this cost many times over.
Ensuring that you don’t ‘over-govern’ by introducing too much red tape that gets in the way of business is crucial. One thing that we do in projects is create an Excel dump of all content types. This exposes the site columns so that people can choose from a selection of Enterprise content types searching by both content type name and available metadata.
Summary
We do recommend adding governance of SharePoint content types to all implementations. The cost of doing so is a little upfront planning and training but if done properly can come with a huge pay-offs as noted above.
Much has changed with the publishing process of content types in SharePoint from the move from on-premises to the cloud, and the issues we used to face around delays around publishing don’t exist anymore. For more learning, we recommend an article that summarizes What’s changed in content type publishing (microsoft.com).
Reach out if you need help with the governance of content types – we’d be happy to advise and chat!
