SharePoint's Document ID Service and Prefixes

I have had some recent conversations about SharePoint Document IDs.  Specifically, Document ID prefixes and now I have some thoughts about them I would like to share.

The SharePoint Document ID Service is something that Microsoft added in SharePoint 2010 (continued in SharePoint 2013) and it was a welcome addition to the product line.   A fundamental requirement for ECM, document and records management is to be able to uniquely identify a document and be able to retrieve the document by that identifier.  The new SharePoint Document ID service did that, sort of.

In my opinion, Microsoft only went part way with the Document ID Service. The generated document ID is only unique to the site collection. Ideally, the ID should be unique across the entire SharePoint farm(one of the key gaps in OOTB SharePoint that Collabware CLM addresses, but I'll get to that later).

So how did Microsoft address this?  Microsoft provided customers with the ability to add in a custom prefix on each site collection to force uniqueness.

I don't have a problem with having a customer managed field to support uniqueness across site collections. But things start to get messy when organizations start to use this Document ID prefix for business logic, coding and routing purposes.  The Document ID is no longer just for the purposes of ensuring uniqueness, it serves two masters.

An organization may have a requirement to know "From which site collection did this document originate?".  The collaboration site organization may be used to route content to downstream systems or to have workflow behavior based on that original location.  This is a perfectly valid requirement.

The quick and easy way for SharePoint teams to meet this requirement is to use the Document ID prefix.  But is that really the best solution?

By using the Document ID to carry this additional business data, you are now using one metadata column for two totally different purposes.  In my years as a developer and database designer, we referred to these as 'Smart Keys' and were considered bad database design in most cases. So why is this a problem?

1. If you need to use the same prefix across different site collections, you risk having a duplicate document ID issue or you have to create alternative prefix values (LEGAL1, LEGAL2, etc). You then have to explain to end users what LEGAL1 is versus LEGAL2, or change downstream logic to accommodate the new values resulting in additional maintenance costs.
2. The prefixes are not managed through a managed metadata service and cannot take advantages of the benefits of this for search indexing, governance etc.
3. In order to use the prefix on its own, you need to substring out the value from the Document ID field, making searching, sorting grouping and filtering by the original document location (Document ID Prefix) more complex.

In my opinion, a much better way to meet this requirement is to create a custom managed metadata column for the purpose of identifying the originating site collection or department.  Add it to the highest level content types (Document/Document Set level) that you want to manage (so it propagates to their children) and default the value at the site collection level.  You can either leave the column exposed for end users to see or you can hide it.  This now become a useful piece of metadata that has business value, and can be used to search, sort, group or filter your SharePoint content.  You can also apply business logic to it with the content organizer or a downstream workflow if you wish.

Collabware CLM addresses the unique ID challenge by replacing the SharePoint OOTB Document ID service provider with our own.  We even create our own unique ID (we call it the Content ID) and it applies to ALL SharePoint items added anywhere in your SharePoint farm, even in a multi farm situation.  The Document ID is still there, we just replicate our new Content ID value out to the Document ID if one does not already exist.  We made an architectural decision to NOT support document ID prefixes because we believe it is not best practice information design and governance.

End users can include the Content ID values inside document footers (as a unique document reference) and by typing (or copy/pasting) a content ID into any SharePoint search box and pressing enter, your single unique document will be there.

Collabware CLM also provides a URL service that uses the Content ID and will follow that document where ever it ends up moving to in your SharePoint environment, even the record center.  Once you copy a Collabware CLM URL into an Email, document or database column, the link will always find the document if the user has the necessary access permissions.

If you have a requirement to know the original location of a document or other SharePoint item, consider the benefits of the managed metadata approach to meeting the requirement and don't be lured into simply putting some unmanaged text or digits onto the front of the Document ID.

We hope you found this article insightful! To learn more  on records management in SharePoint, check out our blog!  To find out more about Collabware CLM, download our free brochure: