I have been promoting Document Management with SharePoint for many years now and I’m still convinced that enterprises will benefit a lot if they move their files from a file-share to SharePoint. Although managing files in SharePoint libraries usually solves a lot of problems enterprises encounter with saving their corporate files to file-shares, there are some issues that impact the user experience negatively. One of these issues has been the way employees access files if the files are moved to different locations. To understand this issue, we need to have a look at the Document Lifecycle first.
Document Management is not only saving documents to SharePoint libraries instead of saving them to folders in a file-share. A Document Management System should at least support a basic document lifecycle. A document undergoes different stages during its lifetime. A typical document lifecycle could look like this, but there are also more extensive definitions:
Let’s have a look at a common scenario to understand the basics of a document lifecycle. If an important document is created, usually a team is working on this document and this team usually is using a SharePoint team site to collaborate. As long as this document is saved to a document library that is part of this team site, everyone can access this document by its URL – assuming he or she has appropriate permissions. This is what the document lifecycle describes in its ‘Create’ phase.
When the work on this important document has been finished, it is usually reviewed by using an approval process based on a workflow. When the document is approved, it is usually saved to a different SharePoint library. This can be a library for official documents in a company. The document lifecycles refers to this as the ‘Distribute’ phase. It is obvious that this document can’t be accessed by its ‘old’ URL anymore, because it has been moved to a new library and because of that the ‘old’ URL gets invalid.
Same is true for the additional steps of a basic document lifecycle. There is another scenario which leads to invalid document URLs. Sometimes it happens that a company decides to restructure their intranet. As soon as documents are moved to a new location, they can’t be accessed by their old URL anymore, because the URL changed because of the move. Same is true if the document is renamed.
Let’s see how this looks like. The following screenshot shows a common document library in SharePoint 2016. I just added a new document to this library:
To retrieve the URL of this document, we can simply click on the three ellipses. SharePoint 2016 will show a pop-up with the accounts that this document is shared with and it’s URL. The URL of my sample document is looking like this:
https://sp2016b-mj/sites/wirkus/Shared%20Documents/Important%20document.docx
If this document is moved to a new library, it can’t be retrieved by its URL anymore, because the name of the old library (“Shared Documents”) is part of the URL. Same is true if the document is moved to a different site, because the name of the site (“wirkus”) is also a part of the URL.
SharePoint provides a solution for this by leveraging Document IDs. In simple terms SharePoint is using an internal service to add a unique number to each newly created document. Because this service is running in the scope of a site collection, the IDs are unique only within the same site collection. To overcome this limitation, a custom Document ID provider can be created or a prefix can be configured. If you are interested in how to do this, I encourage you to have a look at this blog post I have published some months ago.
Setting up Document IDs is very easy – you only need to activate the corresponding site collection feature:
If you add a new document to a library with Document IDs turned on, SharePoint will assign a new Document ID to the document. The URL of the document is looking different now:
As you can see, the URL of the document does not contain any document related information now – except the Document ID. Instead, it redirects to a SharePoint page (called DocIDRedir.aspx) and adds the Document ID of the document as a parameter. This page leverages a control that takes the given Document ID and looks for the document. Although this involves an additional step, a user usually does not recognize this additional step when accessing a document by its DocumentID-based URL.
The creation of the Document IDs is managed by two different timer jobs just the same way it was in SharePoint 2013:
Based on my findings using the current public beta of Microsoft SharePoint 2016 (Version 16.0.4316.1217), it looks like Microsoft just enhanced the Document ID services of SharePoint 2013 a little to make it more user-friendly. That’s the reason why I assume, that this service is working in SharePoint 2016 almost the same way as it did in SharePoint 2013.
To understand how this service is working internally, we should have a view on the code needed to create a custom Document ID provider. The basic framework of a DocumentID provider looks like this:
Each Document ID provider needs to expose a method that generates a new Document ID. This method is named GenerateDocumentId(SPListItem item). It is called by passing one parameter only: the SharePoint item that should get a new Document ID. The Document ID provider is creating a new Document ID and it internally joins it with the SPListItem it gets when the method GenerateDocumentId()is called. That’s the reason why the Document ID provider is able to create an internal list of all the Document IDs it has created and their joined documents. The Document ID provider uses this internal list to retrieve documents based on their ID. To leverage that functionality, each Document ID provider exposes another method: GetDocumentUrlsById(SPSite site, string docID).
This method is called by SharePoint to retrieve a document by its DocumentID. Basically, this is what the page DocIdRedir.aspx does. This method is called with the current site and the Document ID as parameters and it is supposed to return the URL of the joined document. If the document can’t be found in its internal list, each Document ID provider is using the SharePoint Search Index to retrieve the URL of the document. In the end, this is the reason why SharePoint is able to retrieve a document by its Document ID even if this document has been moved to another site collection. Although a different Document ID provider is involved if the document has been moved from one site collection to another site collection (because a Document ID providers is site collection-scoped), this different provider can still use the SharePoint search to retrieve the document.
Based on the current beta version of SharePoint 2016 it appears, that Durable Links are the ‘old’ DocumentIDs with minor enhancements.
Written By:
softlanding
Softlanding is a long-established IT services provider of transformation, professional services and managed IT services that helps organizations boost innovation and drive business value. We are a multi-award-winning Microsoft Gold Partner with 13 Gold Competencies and we use our experience and expertise to be a trusted advisor to our clients. Headquartered in Vancouver, BC, we have staff and offices in Toronto, Montreal and Calgary to serve clients across Canada.
More By This Author
