sp-dev-docs icon indicating copy to clipboard operation
sp-dev-docs copied to clipboard

validateUpdateListItem causing PowerAutomate flow to trigger

Open adam13hylo opened this issue 4 years ago • 8 comments

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint REST API

Developer environment

Windows

What browser(s) / client(s) have you tested

  • [ ] 💥 Internet Explorer
  • [X] 💥 Microsoft Edge
  • [x] 💥 Google Chrome
  • [ ] 💥 FireFox
  • [ ] 💥 Safari
  • [ ] mobile (iOS/iPadOS)
  • [ ] mobile (Android)
  • [ ] not applicable
  • [ ] other (enter in the "Additional environment details" area below)

Additional environment details

  • PowerAutomate with per user plan.
  • Web region set to (UTC) Dublin, Edinburgh, Lisbon, London
  • Web Locale set to English

Describe the bug / error

Currently I have a very simple PowerAutomate flow that is triggered on item creation or modification. The flow is associated with a very basic list containing just a title column for testing purposes. Using the 'validateUpdateListItem' endpoint along with the SharePoint HTTP action I am trying to update the title.

When testing this the list item is updated as expected, and the version does not increment, however the PowerAutomate flow is triggered again as if the list item has been modified.

When inspecting the body of the trigger when the flow is triggered I can see that the modified date is an hour behind that of the actual modification time, as an example: ModifiedDate

Even when converting the date to UTC using a PowerAutomate expression in the body of the HTTP Post action I am finding that the flow is being triggered multiple times, as an example:

image

Currently the HTTP Post Action is configured as so:

Endpoint https://tenant.sharepoint.com/sites/sitecol/_api/web/GetList('/sites/sitecol/Lists/mylist')/items(22)/ValidateUpdateListItem()

Method Post

Headers

{ "Accept": "application/json;odata=nometadata", "Content-Type": "application/json;odata=nometadata" }

Body

{"formValues":
	[
{ "FieldName": "Modified", "FieldValue": "2021-10-21 22:52:36" },
{"FieldName":"Editor", "FieldValue":"[{'Key':'[email protected]'}]"},
{"FieldName":"Title","FieldValue":"UpdatedTitle"}
	],
		"bNewDocumentUpdate":true
}

Steps to reproduce

  1. Create Automated Cloud Flow
  2. Select 'When an item is created or modified' trigger
  3. Set trigger to be associated with SharePoint list.
  4. Add 'Send an HTTP request to SharePoint' action to flow.
  5. Set the method on the action to 'Post'
  6. set the URI to:

/_api/web/GetList('/sites/validateupdatelistitem/Lists/ValidateUpdate')/items(@{triggerOutputs()?['body/ID']})/ValidateUpdateListItem()

  1. Set the headers to the following:

{ "Accept": "application/json;odata=nometadata", "Content-Type": "application/json;odata=nometadata" }

  1. In the body set the form values, these have been set as follows:

{"formValues": [ { "FieldName": "Modified", "FieldValue": "@{convertFromUtc(triggerBody()?['Modified'], 'GMT Standard Time', 'yyyy-MM-dd HH:mm:ss')}" }, {"FieldName":"Editor", "FieldValue":"[{'Key':'@{triggerOutputs()?['body/Editor/Email']}'}]"}, {"FieldName":"Title","FieldValue":"UpdatedTitle"} ], "bNewDocumentUpdate":true }

  1. Create new list item in the list associated with the flow, the flow should trigger multiple times.

Expected behavior

I would expect the list item title to be updated but that the flow would then not run again, this is a tried and practiced method I have used before and it has only recently started happening so I am not sure if this is a bug with PowerAutomate or a change with how the 'validateUpdateListItem' endpoint works.

adam13hylo avatar Oct 21 '21 21:10 adam13hylo

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

ghost avatar Oct 21 '21 21:10 ghost

Any Update on this?

Varinder-netizen avatar Aug 09 '23 10:08 Varinder-netizen

I just bumped into the same issue when I didn't set the editor field. This then results in the account used by the flow to become the new editor/Modified By.

I found however that when I set the Editor field this behaviour changes. In my case I'm setting the editor to the owner of the item/document (so in effect not making a change), and now my flows are not triggered (as expected!) and my version history in SharePoint not being updated.

So it look like the SystemUpdate does work however the Editor needs to be set.

Looking at the above example.

Editor is being set to the following value: [{'Key':'[email protected]'}]

This should be a claim rather than an email address and then it should work.

Pieter-Veenstra avatar Jan 05 '24 14:01 Pieter-Veenstra

Hi @Pieter-Veenstra can you elaborate on what you mean by this should be a claim rather than an email address please? DO you mean it should be:

[{'Key':'i:0#.f|membership|[email protected]'}]

adam13hylo avatar Feb 21 '24 16:02 adam13hylo

We are seeing the same issue. Steps to reproduce:

  1. Create Automated Cloud Flow
  2. Select 'When an item is created or modified' trigger
  3. Set trigger to be associated with SharePoint list.
  4. Add 'Send an HTTP request to SharePoint' action to flow.
  5. Set the method on the action to 'Post'
  6. set the URI to: /_api/Web/Lists(guid'4f602c4b-3563-4193-b729-cbd97cbd065f')/Items(1)/validateUpdateListItem()
  7. Method: POST
  8. Headers: Key Value accept application/json; odata=verbose content-type application/json; odata=verbose
  9. Body { "formValues": [ { "FieldName": "Title", "FieldValue": "SilentUpdate" }, { "FieldName": "Modified", "FieldValue": "2024-04-16 04:20:02" }, { "FieldName": "Editor", "FieldValue": "[{'Key':'i:0#.f|membership|[email protected]'}]" } ], "bNewDocumentUpdate": true }
  10. OUTPUTS { "d": { "ValidateUpdateListItem": { "__metadata": { "type": "Collection(SP.ListItemFormUpdateValue)" }, "results": [ { "ErrorCode": 0, "ErrorMessage": null, "FieldName": "Title", "FieldValue": "SilentUpdate", "HasException": false, "ItemId": 1 }, { "ErrorCode": 0, "ErrorMessage": null, "FieldName": "Modified", "FieldValue": "2024-04-16 04:20:02", "HasException": false, "ItemId": 1 }, { "ErrorCode": 0, "ErrorMessage": null, "FieldName": "Editor", "FieldValue": "[{'Key':'i:0#.f|membership|[email protected]'}]", "HasException": false, "ItemId": 1 } ] } } }

Modified field value is set using formatDateTime(triggerOutputs()?['body/Modified'],'yyyy-MM-dd hh:mm:ss') Editor field value is set using [{'Key':'@{triggerOutputs()?['body/Editor/Claims']}'}]

Flow keeps retriggering until it is saved with a Terminate action before the Send an HTTP request to SharePoint action.

Does anybody have an example of this technique for silently updating without retriggering currently working?

Is there an alternative technique we should pursue?

Ron-Rohlfs avatar Apr 16 '24 16:04 Ron-Rohlfs

We are now able to use the validateUpdateListItem endpoint to update a list item without retriggering the flow (i.e., found and resolved the problem). Issue was the Modified field value in the body of the Send an HTTP request to SharePoint action was not set to the Modified value of the list item in the initially triggerred instance. The timezone for the site hosting the list is: (UTC-08:00) Pacific Time (US and Canada). The Modified field value in the body of the Send an HTTP request to SharePoint must to be set to: convertFromUtc(triggerOutputs()?['body/Modified'],'Pacific Standard Time','yyyy-MM-dd HH:mm:ss'). The datetime format string must use HH, not hh, so the result uses the 24 hour format.

Ron-Rohlfs avatar Apr 18 '24 20:04 Ron-Rohlfs

I have tried using the validateUpdateListItem endpoint by setting the Editor and Modified fields, along with my own field, but the flow still ends up in an infinite loop.

My entire body looks as follows:

{
    "formValues": [
        {
            "FieldName": "CustomConcatField",
            "FieldValue": "@{join(body('Select'),';')}"
        },
        {
            "FieldName": "Modified",
            "FieldValue": "@{addMinutes(triggerOutputs()?['body/Modified'], 120, 'yyyy-MM-dd HH:mm:ss')}"
        },
        {
            "FieldName": "Editor",
            "FieldValue": "[{'Key':'@{triggerOutputs()?['body/Editor/Claims']}'}]"
        }
    ],
    "bNewDocumentUpdate": true
}

I have verified the Modified date field and that is set to the correct value. Within the SharePoint UI it also state the same value after the update as before the update.

Interestingly enough I do not get a new version when examining the version history and as mentioned the Modified and Editor fields are kept the same, but still my flow re-triggers.

mblennegard avatar Jun 07 '24 14:06 mblennegard

in the flow, this worked for me:

{ "formValues":[ { "FieldName": "Title", "FieldValue": "changed from flow" }, { "FieldName": "Author", "FieldValue": "[{'Key':'@{triggerBody()['email']}'}]" }, { "FieldName": "Editor", "FieldValue": "[{'Key':'@{triggerBody()?['email']}'}]" } ], "bNewDocumentUpdate": true }

I'm getting user UPN from input values of a Manual trigger as a testing scenario.

1

blumenhause avatar Sep 18 '24 11:09 blumenhause

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.

github-actions[bot] avatar May 02 '25 15:05 github-actions[bot]

This issue poped up this week on multiple environments that I maintain with different solutions. It all worked at least till last week that i know, and now all the flows that do a "silent update" keeps triggering it self.

Other people having the same issue? I didn't found a solution yet, above solution to had Editor wasn't needed anymore and putting that in doesn't solve it this time.

DAGiessenburg avatar Aug 21 '25 15:08 DAGiessenburg