SharePoint Move File action breaks Document ID Service assigned value

[SimonChalfont]

We have had a system in production for a couple of years now, however, in the last week or so we have observed that the Move File action in Flow results in the moved document being assigned a new Document ID when the Document ID Service feature (https://support.office.com/en-gb/article/enable-and-configure-unique-document-ids-ea7fee86-bd6f-4cc8...) is enabled in the Site Collection. This is a change in behaviour for the action as this was not happening previously. To compound this, the native "Move to..." action in the UI works flawlessly and preserves the Document ID assigned to the item.

Below is a screenshot of "LibraryA" showing 3 documents, each with a value assigned to "Document ID" by the Document ID Service. I have duplicated these values in a text field called "DocumentID History".

I have a Flow that is configured to run when the file is created/modified and a Yes/No field (not shown) that permits a document to be moved, via the Move File action, from LibraryA to LibraryB.

Below is the screenshot of after "DocA" was moved via the Flow and "DocB" was moved using the native "Move to" button in the Action Bar.

Notice that the Document ID value has been replaced in "DocA" but not "DocB".  This behaviour was not happening a week or so ago and so represents a change in the way the File Move action appears to be working.

I have raised a ticket with the Power Platform Support but thought I'd share this with the community now.

[v-bacao-msft]

Hi @SimonChalfont ,

Thank you for sharing. If you just configured the Move file action and didn't make any other settings, then this change is weird.

Best Regards,

[SimonChalfont]

Hi Barry, 

Thanks for replying. Yes, it's more than weird; it's plain broken. It's ludicrous to have 1 behavior when moved via the UI and a completely different one when moved via Flow/Automate. It also completely undermines the value of the Document ID Service and breaks the fundamental promise that it "Assigns IDs to documents in the Site Collection, which can be used to retrieve items independent of their current location."

What's worse is that if you try to use DocIdRedir.aspx link with the expected Document ID then it is unable to locate the document.

Just to re-iterate, this is a change in the File Move action that has happened in the last week or so. It has been working as expected for over a year. 

I've been on a support call this morning and hopefully it will find its way to someone in the Engineering Team who will understand the impact. At the moment, we have a broken document management system for our finance team.

[v-bacao-msft]

Hi @SimonChalfont ,

Thank you for your reply and look forward to the appropriate explanation or any solution given by MS Support.

If so, please share it with us.

Best Regards,

[SimonChalfont]

Regrettably, if somewhat predictably, Microsoft Support has come back and reported that according to their “Subject Matter Expert” the Flow action is working as expected.  I have refused to accept that response and asked for the name of the person who has provided that assertion.

I have also reiterated the point that the recent change to the Move File action breaks the promise of the Document ID Service in SharePoint. As defined, the Document ID Service “assigns IDs to documents in the Site Collection, which can be used to retrieve items independent of their current location.”  The very essence of this feature is that it guarantees that when a document is assigned a value, then that value persists even if that document is moved to a different location. This guarantee is an absolute cornerstone of Enterprise Content Management and having Flow/Automate now break that promise is a serious issue that should be escalated quickly.

The impact is that in highly governed information management environments (i.e. legal, financial, healthcare) the Document ID value is considered sacrosanct and anyone who might have built their document filing routing logic using flows will now be facing a very serious issue as those values are now changing when before they did not.  The moment someone senior in either the SharePoint or Flow teams realises this then they will realise that a mistake has been made.

In my view, the issue is that in SharePoint/Flow terms, a Move File action is really just a Copy File followed by a Delete File and I suspect that code that was previously there to ensure the metadata of the item, including the Document ID, is preserved from the source item has been changed and as a consequence the Document ID value is being set on the copied item as if it is a new document (which technically it is) and not replaced with the original value (so as to keep it a “move”).

[Anonymous]

Has there been any feedback from Microsoft on this?  I've just tried using the Move File action and the SharePoint assigned ID also changes, incrementing by 3 every time the file is moved.  This action does not do what you would expect or the documentation describes and needs to be fixed.  How do we raise this to Microsoft?  Do we have to submit an 'Idea'?