As we announced today on Office Blogs, we are happy to see SharePoint evaluated as a Leader in The Forrester Wave™: Enterprise Content Management—Business Content Services, Q2 2017.


Our pivot to content services began at Ignite 2016 in Atlanta where Jeremy Mazner and I presented a breakout session on SharePoint ECM. You can watch the entire session below:


At Ignite 2016, we reviewed some best practices for traditional ECM and Content Services.  Let's take a look.


Minimize ECM in default libraries.  The default team site document library is the common repository for many other collaborative elements of Office 365.  Creating a team site automatically enables other apps, such as Planner and Teams, that sit on top of the SharePoint foundation; they all use the default document library for the team site.


What does this mean?  For starters, avoid heavy customization of that library.  Adding a lot of custom metadata columns and making them required will have unanticipated impacts on those other apps.  If you want to create custom ECM processes and data, just add a new library to your site, or use a repository template like a Document Center.


Reuse common fields as site columns.  We demoed this at Ignite as well.  Although there’s nothing wrong with using a one-off column on a single document library, many times the same field is needed in more than one place.  It’s a best practice to create these fields as site columns so they can be shared through the site collection.  And if they require “choices”, defining them as Managed Metadata columns is the preferred way to assume a single definition can be shared through the information hierarchy.  With the new release of Feature Pack 1 for SharePoint 2016, you can also share those metadata definitions with an on premises environment.  That means you can add the same look up value to all your content in libraries on premises and in the cloud.


Do not overwrite default content types.   95% or more of all content types used in SharePoint libraries are the default content type, “Document”.  It has no template, no required metadata, and no retention policy by design.  Although you may be tempted to updated this content type, resist the urge!   Instead, create a child content type that inherits its base definition from Document.  That way, Microsoft updates can’t override your customizations.  And if you put the content type in a Content Type Hub, you can share that definition through your on-premises or cloud architecture.



Minimize MMS complex pinning, reuse if hybrid is on roadmap.  If you’re planning to rollout Hybrid Taxonomy, the simple design pattern is that the cloud is the “parent”, and on premises term sets are the child.  That means local techniques for reusing terms inside the same architecture, such as pinning, create a local “master” tag which will be overridden by the online master.  We recommend using the PowerShell command Copy-SPTaxonomyGroups to copy preexisting terms from on premises to SharePoint Online as the new “master”. 


As a result, try to unwind any pinning or reuse until you’ve created a hybrid architecture first.


Strategize use of hub-based content types (don’t overdo it!)  We remind you about stories about the companies with, for instance, 1400 content types because they are great cautionary tales.  Even if its supported, conceptually it’s hard for users to leap from “Document” to 1400 or more syndicated content types.  Ideally, you syndicate the most heavily and widely used types of content (contracts, presentations, policies) while allowing for localized definitions or inheritance to accommodate regional or divisional variations.


Hashtags, keywords?  Be careful…  Ad hoc classifications such as Delve boards, social hashtags or Enterprise Keywords let users create any possible term or variation including misspellings.  Providing content services at scale across the enterprise usually mandates a higher level of precision and predictability.  The Managed Metadata Service (MMS) is likely a far stronger framework for classification in ECM scenarios.

Valued Contributor

 @Chris McNulty Great stuff. One thought though: you make it clear that Delve Boards are ad hoc. So is the plan to leverage MMS in Delve or is the intention to deprecate Delve Boards? Delve Boards are certainly within Microsoft's domain to manage in a way other hashtags and keywords are not. From an enterprise perspective being able to turn off Boards might be an option to ensure Best Practices as described. Thoughts? 


Is none of the above an OK answer? Getting synergy among MMS, hashtags, labels and boards for search and discovery is a big issue that isn't a quick rollout but is being planned.

Valued Contributor
@Chris McNulty I appreciate the direct reply and also a 'quick fix' isn't achievable or desirable. However, a very clear roadmap IS necessary as businesses invest in different routes into Office 365. Knowing a plan is coming is good:as a strategy guy my life is plans, but operationally a short term roadmap is a necessity. My short term measure would be to stop Delve Boards being used to reduce ad hoc classifications but there is no way to currently do this AFAIK without disabling Delve which I would not choose to do. So I'm currently impeded from implementing your recommendation in this respect. I do understand how complex this subject is and hope my contribution to a dialogue around this is received well. That is certainly my intention. I look forward to further news in May and September!
Occasional Contributor

@Chris McNultyWill Hybrid Taxonomy work with Open Submission Policy type termsets so that if end user creates terms in Onprem site, it gets replicated in the Term Store in SPO. Other than that, what is the use of Open Submission Policy type termsets being synced from SPO to SP-Onprem.

Senior Member

@Chris McNulty Any update on this? if i am to drive adoption for a large userbase for delve and sharepoint i need to know that they are going to be able to find what they need