Have you ever struggled to handle file locks in SharePoint when you are running your flows?
File locks and actions in Power Automate
Power Automate’s actions that deal with documents in SharePoint, will have to deal with the same issues that users may deal with, however users have the SharePoint UI that will help them. In flows you will need to deal with it!
In SharePoint there are a number of file locks that may happen:
- A user checks a file out
- Another user checks the file out
- A System Account checks a file out (this can happen when you declare a file as a record)
- A user locks the document by opening a file
What happens when a file is locked?
First of all, what happens when a file is locked in SharePoint and a flow tries to update properties?
The request will fail:
When a document is locked (or open by a user in a browser or client app) for editing then you will receive the following:
The file \”https://pieterveenstramvp.sharepoint.com/Shared Documents/Document.docx\” is locked for shared use by pieter@pieterveenstramvp.onmicrosoft.com.
The file \”https://pieterveenstramvp.sharepoint.com/Shared Documents/Document3.docx\” is checked out for editing by i:0#.f|membership|testuser@pieterveenstr.
The file \”https://pieterveenstramvp.sharepoint.com/Shared Documents/Document.docx\” is checked out for editing by SHAREPOINT\\system.
Get the Checked Out User
To get the checked out user you can simply look at the document properties on the library:
This can be collected using the following REST API call:
Get the Locked By User
Next Steps
Once you have identified your steps that are potentially affected by document locks, you might want to build retry steps in your flows. Please have a look at the Flow Retrying Pattern for more details
Great write-up!
Could you provide more details on the api string in the image for GetFolderByServerRelativeUrl. There is a FX replace and a ServerRelativeUrl that are obscure.
Thanks!
Hi Brad,
The replace removes the server part (https://xyz.sharepoint.com) of the url so that we get a server relative url (/sites/anysite/…)
The d/ServerRelativeUrl comes from the trigger.
For more info on querying json see also:
https://sharepains.com/2019/09/16/query-json-in-microsoft-flow/
Hi Brad, I too had difficulty with this then finally figured it out – do you still need help?
I found this useful. Thank you. I’m just going to add a sample URL here as i see some people asking for samples:
https://mytenant.sharepoint.com/sites/mysite/_api/web/GetFolderByServerRelativeUrl('/sites/mysite/Shared%20Documents‘)/files/getbyurl(‘/sites/mysite/Shared%20Documents/MyFile.xlsx’)/lockedbyuser
Thanks
Most times you have already the ID of the list item/file. When so, a much shorter URL:
https://mytenant.sharepoint.com/sites/mysite/_api/Web/lists/getbytitle('library%20display%20name‘)/items(itemid)/File/LockedByUser
When you have the id then that will indeed work.
“lockedByUser” http request (REST API) will not work correctly when multiple users edit the document (co-authoring).Http request will return only the UserPrincipalName of the first user editing the document. If the document has been closed or not in edit by first user and it is still open in edit (locked) by other users, the request will still return the first UserPrincipal as lockedbyuser. MS needs to fix this…
Hi Ionel,
I had a bit of a further look into this.
I opened the same documents as two different users and as I was editing the document, my flow that tried to update properties and read who locked the document would give me details on the locking user.
So far I found that the user who last edited/typed into/updated the document is the one that is reported as the locking user.
This is how I expected it to be.
When I was testing this however I found every now and then that things were slightly delayed. Also during my tests I used the Browser version of Word only. So I wonder if the Auto save of documents creates the confusion. So it might just be a matter that the lock happens on saving or on the start typing after a save or anything like that.
I wonder what happens when two users indeed both type in a separate section of the document. Technically you should then have two users locking part of the document.
It’s frustrating that there’s no administrative “unlock” method available to PowerAutomate Flow authors. Having a flow wait in a Do Until loop until the file unlocks is a horrid solution – considering that the unlock isn’t always triggered upon the user exiting their file!
An easier way is to use child flows with long retry configurations