Today I wanted to update Documents/Items without triggering other flows. The ValidateUpdateListItem endpoint in the REST API made this System Update possible.
System Updates vs Updates
Table of Contents
Normally when an item is updated in SharePoint, flows that are triggering on the list will run. Sometimes however, you might want to update the triggering list item with for example a new status value on the status field without triggering flows.
If you want to do this update and you don’t want a flow to trigger you can do a System Update. Silent update may be a better term for this, however in the SharePoint world this has been called System Update for quite a while.
When would you want to do a silent update? Imagine that the update of an item in SharePoint triggers a flow. Then the flow updates that same item, for example a status field is set to processed. You would now potentially end up in an endless loop of updates. And Silent update could avoid this.
So how can we do a silent update within a flow in Power Automate?
First I’m going to have a look at the REST API, ValidateUpdateListItem endpoint
The ValidateUpdateListItem endpoint
I have implemented my system update as part of a child flow so that I can call this silent update from other flows, without having to repeat the logic of the system update. Reusing code when possible is always a good idea.
Using the Send and HTTP request to SharePoint action we can construct the following action.
I’m taking the SiteUrl, the Item ID and the Update details as input for my System Update action. The above screenshot show an example of this.
I’m going to have a look at the formValues in a bit. First I will have a look at the bNewDocumentUpdate property.
The bNewDocumentUpdate we can set to true or to false. When this property is set to True, no new versions are created. Well …
This pain that I bumped into made me think for a while that the System Update didn’t work anymore. And I’m not the only one. On GitHub I found the same issue:
https://github.com/SharePoint/sp-dev-docs/issues/7424
Within the System Update we have to include the Editor field. Without the Editor field being included a new version is added to the updated item. So if you decide to use the end point mentioned make sure that you include the Editor.
Update Details
For an update to be successful we could set the formValues as shown below.
{"formValues": [
{ "FieldName": "LastUpdatedFromFlow",
"FieldValue": "2024-01-05 12:30.44"},
{ "FieldName":"Subject",
"FieldValue": "Document5.docx"},
{ "FieldName": "DocumentType",
"FieldValue" :"Letter" },
{ "FieldName": "Editor",
"FieldValue" : "[{'Key':'i:0#.f|membership|pieter.veenstra@mytenant.onmicrosoft.com'}]"
}
] ,
"bNewDocumentUpdate":true
}Notice that formValues is an array of objects with the following two properties:
- FieldName
- FieldValue
In the above example Subject is a simple text field, LastUpdatedFromFlow is a date field and DocumentType is a choice field. Editor is the out of the box modified by people field.
The way these system updates are configured are actually really good as the updates of most types are simply done by supplying the value that a user would see in the SharePoint User Interface.
The Editor
As mentioned the editor field is very important. And as mention in the above GitHub issue, the Editor needs to be set tot he Claim of a user ( with that “i:0#.f|membership|” stuff in front of the account) and otherwise it will not work.
Locked files
Do you remember locked files in SharePoint, well this approach is not affected by locked files. So you can update document properties without the need for a user to close the file. So you could compare this system update a bit with Co-Authoring.
FAQs
What is a system update in SharePoint?
A system update is an update that doesn’t trigger any alerts or flows. It is like the system is overwriting it’s normal behaviour by accepting an update without triggering any other processes. It is often used to allow updates to for example a status field, while other updates should trigger other processes.
Discover more from SharePains
Subscribe to get the latest posts sent to your email.
This appears to be specific to document libraries and not really applicable to “Lists”.
Is that a correct assessment?
You can do the same update on lists. However you will find that version history is more often enabled on Document libraries than on lists.
validateupdatelistitem isn’t actually a traditional CSOM systemupdate (although it is similar), and it has a slightly different effect (some stuff around major/minor versions, the modifedby and modified date values, checked out documents etc.).
It is possible to do a CSOM systemupdate using SP Http in power automate, although a little more complex, but sometimes needed as it is the only truly ‘no-touch’ way to update lists/libraries in sharepoint. Mikael Svenson explains it here:
https://www.techmikael.com/2019/04/disable-event-firing-when-flow-updates.html
This is great news for the Locked Files issue. I haven’t had a chance to try your approach yet, but certainly glad there’s potential to work around that issue.
I did have a chance to test with Locked files. And my test was negative. So a locked file was still blocking for this operation.
Did the flow lock the file or did some other user lock the file?
The issue I came across with this approach is that if the flow is run by same user that has checked out document, it would work but otherwise it won’t. For example, in certain cases a service account would be running the flow and it fails in that case as the document is checked out by another user (a sharepoint user).
Another observation is that if the document is checked out, this approach checks the file back in and modified by (Editor) will be set as the user running the flow which is service account in my case and ignores the Editor claims provided in the form values.
Tested and it works! very important to include the Editor field, it doesn’t work otherwise. Thank you so much for saving my bacon!
Hi Pieter,
I seems that this is not working anymore. I use this end point in a solution that I’m building the last year, exactly to avoid triggering flows. I never have used the Editor in my update. It worked fine till a couple of weeks ago. Did a test with the Editor (and title and Author, and other combinations) in the update and that didn’t resolve the issue.
Is there a issue with the end point that you know of, or is there nowadays a better solution to do this?
I made an Github issue (https://github.com/SharePoint/sp-dev-docs/issues/10377)
Hi Daniel,
I’m just implementing the same for one of my clients and it still works however, to avoid locking issues I had to include a parameter
“sharedLockId”: “@{body(‘Send_an_HTTP_request_to_SharePoint_-_Get_Lock’)?[‘d/vti_x005f_sourcecontrollockid’]}”
Where the referenced action in the above expression runs a GET on the following endpoint: _api/web/Lists/GetbyTitle(‘My Document Library’)/items(@{triggerBody()?[‘number’]})/File/Properties
I have noticed however that the process that is locking the process initially seems to blank out the updates that I’m trying to make.
Hi Pieter,
You talking about when another user or other flow locks the file, you get a locking error.
423 – this file is locked for shared use … Dennis Goedegebuure has a nice blog article about that. I think what you describes is what he explains in that article. https://www.expiscornovus.com/2024/10/23/update-a-locked-file-property/
I don’t have a locking problem, I have the problem that “Send an Http Request to SharePoint” action with ValidateUpdateListItem keeps triggering a modification (modify) action on the item or file.
I have it done that it is not a new version of the file or item, but http request updates the current version. Only it still triggers a modification with starting the flow again, so i end up in a endless loop of flow runs.
Or did I get you wrong and did you solve this endless loop by adding the extra parameter “sharedLockId”.
I will test it again in a few different locations.
Which location is your environment running in?
Hi Pieter,
The location of the different tenants are in: European Union\EFTA
We now mostly testing on updating a list item, I will run a test in coming days if it behaves different on files. Thanks
I am using this on files only. So that may be the difference.