“I’m using Power Automate to update a backup column with each user update on the item, how can I do it without doubling the item version?”
For some solutions, e.g. when triggering a flow on SP column update, you might need a ‘backup’ column. A column you’ll use to store a previous value of another column when user updates it. But if you have a separate action to update only that one column, it can mess up your versioning. Each user update will trigger the flow, and the flow will do another ‘sync’ update. One extra item version only to keep the columns synchronized. There has to be a better way to keep the versions under control.
Use HTTP request for the update
The solution is to use HTTP request for the ‘sync’ update. With HTTP request you have more control over the update than with the ‘Update item’ action. While the action allows you only to update columns, with HTTP request you can define additional parameters. And one of the parameters is ‘bNewDocumentUpdate’. By adding the parameter to the request Body you can tell the update to not create another item version.
"bNewDocumentUpdate": trueThe full HTTP request format should be as below.
Uri:
_api/web/lists/GetByTitle('<ListName>')/items(<ItemID>)/validateUpdateListItem
Body:
{
"formValues":[
{
"FieldName": "<FieldToUpdate>",
"FieldValue": "<ValueToUpdate>"
}
],
"bNewDocumentUpdate": true
}
Updating the item with an HTTP request as above will add the ‘sync’ update to the already existing item version.
Summary
Even though Power Automate doesn’t offer such functionality directly, you can still update item column without a new item version. But you should use the ‘bNewDocumentUpdate’ parameter only to update system columns, never to update user columns. For user columns it should be always clear which user and when did an update, and you should never ‘overwrite’ it.
But if you just need to keep the number of ‘sync’ versions under control, it might be an optimal solution. Just keep in mind that even if it doesn’t create a new item version, it’s still an update that can cause infinite trigger loop.
It seems that this solution is not valid anymore. I tried this my own now and I get a error:502 BadGateway.
{
“error”: {
“code”: 502,
“source”: “europe-002.azure-apim.net”,
“clientRequestId”: “a6b7f709-37f0-4bd5-954a-428a9608b913”,
“message”: “BadGateway”,
“innerError”: {
“status”: 502,
“message”: “Additions to this Web site have been blocked.\n\nPlease contact the administrator to resolve this problem.\r\nclientRequestId: a6b7f709-37f0-4bd5-954a-428a9608b913\r\nserviceRequestId: 639af29f-908c-1000-07d7-773ff2c67fab”,
“source”: “https://***.sharepoint.com/sites/ndt-document-center/_api/web/Lists/GetbyTitle(‘Approved%20Documents’)/items(4626)/ValidateUpdateListItem”,
“errors”: [
“-2130575258”,
“Microsoft.SharePoint.SPException”
]
}
}
}
Hello Kevin,
that’s not a flow error, but an error on the side of SharePoint, maybe this: https://technologyblog.rsmus.com/microsoft/microsoft-365/office-365-error-additions-web-site-blocked-mystery-solved/.
I know this is old, but that link does indicate why, but to make it perhaps more prescriptive … you can run the same API call before you make this call, and just change the _ModerationStatus to 2 (draft) and you should be then able to run your command. 🙂
Nice and interesting article. In my case the item updating works perfectly, but it creates a new version (flow is triggered when approval status changes to “Approved” and updates “Editor” field to a certain account, but after flow execution approval status is “Draft” and version is one minor up).
Flow execution has no errors (it simply has the same behavior than having “bNewDocumentUpdate”: false). Any suggestion on what I´m doing wrong?
Rergards
Hello Manu,
I don’t think you can bypass the new version created by the SharePoint content approval functionality, that one does its own updates that’s behind your reach.
Thank you so much for your answer, Tom.
Regards
Is it possible to also avoid a new minor version when updating an column?
ps: we have no content approval. Just major and minor versioning enabled
Hello Jonas,
I never tried that, but I guess you tried it with the solution so my answer would be ‘no’.
Hey Tom,
So going off what you’ve said here “For user columns it should be always clear which user and when did an update, and you should never ‘overwrite’ it. “, we weren’t happy with the functionality with the content approval so I started to put together our own similar one.
It uses the Send HTTP Request for (what’s meant to be) silent column updates – triggered from a PowerApps application – and then uses the Check Out/Check In to maintain Version Control ,while also allowing us to add custom comments – IE document content review updates which SharePoint don’t currently log.
Issue I’m having is the Send HTTP isn’t exactly silent, it’s still coming up within our version control, but with the additional Check In version update too.
I feel like I’ve been rattling my brain over this for too long now, as I’m sure that this used to work.
Could you confirm that Send HTTP does 100% allow you up update a User Column without it being registered within version control?
Hello Patrick,
I never used it with version control, but if you tried it and it doesn’t work then it probably doesn’t work when it’s enabled. It works if you keep only major versions, but with minor versions SharePoint behaves a lot differently.
For anyone that’s coming here, if you run two validateUpdateListItem actions, you can maintain the person who “originally” last modified the item and also set the approval status to Approved. You can include other fields with the Editor / modifiedBy field change.
The Approval Status field has to be run on its own, but it is also transparent, so it will not change the last modified to the account changing the approval status.
Action one = Editor
Action two = _ModerationStatus
Hello Eliot,
thank you for sharing the solution!
Hey Tom, am I right, that the “modified by” column will be overwritten from the HPPT Request? So it is no longer comprehensible who made the last entry. In your example it is not clear who updated the “titel” or “date” column, because the “modified by” will be updated to the user who triggert the update with the HTTP request.
Hello David,
that’s correct, you won’t know that there even was any update via the http request, the changes will merge with the last update done by user in the latest version.