After a struggle with Microsoft Premier support that lasted more than 1.5 years, explaining the issue over and over again to various SharePoint or Office specialists joining (and leaving), TataSteel Europe abandonned the use of unique Document IDs printed in MS Word footers from their Document Management System (DMS).
The SharePoint Document ID Value was added to the page footers.
I am the IT Architect of their DMS in SharePoint Online and know about all the involved bits and pieces by hart.
What is the issue about?
In MS Word files one can use SharePoint field codes or Quick Parts that are then updated to actual entered values in the SharePoint libary where the document is created from a Content Type (with attached Word template).
We found that in some cases (root cause has not been found, despite all attention by all troubleshooting experts), the Document ID value was the one stored in the template (of the ContentType) and NOT the SharePoint value that was correctly generated for the new document in the library.
I wrote a PowerShell script to detect the mismatch between Document ID values in Word and the actual value in SharePoint.
This script showed the issue was wide spread over the whole DMS system, which holds more than 100k documents that are crucial for work instructions, safety, etc. at Tata Steel.
This bug broke the whole idea of having a visual Document ID printed in the footer (so people could always find back the most actual approved version from a hardcopy) that matches the one in SharePoint!
We have tried various things as suggested by Microsoft Premier support, but to no avail:
- Recreate the Content Type from scratch in the latest Office version (as to rule out any Office conversion)
- Recreated the Library as to rule out any Classic SharePoint to Modern SharePoint conversion was at play (this mechanism had functioned fine for years in Classic SharePoint mind you)
- Getting MS SharePoint and MS Office experts working with each other i.s.o. pointing to each other
After all these months we decided that the effort involved to get this feature back on it’s feet was simply too much and advised to stop using it as not being 100% reliable.
Too bad Microsoft broke this mechanism.