How to update SharePoint listitem under current user and not flow owner?

[dreamsat]

I created some custom list with 3 single line of text columns. I created with userA a flow which is triggered when someone create a new list item. In this flow I update this current list item with some dummy value in columnC. It works great, but when I go to version history I see flow modified the value of columnC under the account who created this flow (userA). How can I make this flow is modify the current listitem under its own account?

[Pstork1]

The problem is that Flows that run off an automated trigger run in the context of the maker of the Flow.  So that is who shows up in Modified By.  Manually started Flows, like the ones that start with a button in a PowerApp run in the context of the user who presses the button. So you could use a manual trigger for your Flow and it would update the way you want.  But if you want an automated Flow then the only way to do this is to use a REST call to manually set the Modified By field after making the update.  Here's an article on how to do it.

http://johnliu.net/blog/2019/2/flowninja-hack-78-modifying-modified-by-and-modified-time-with-micros...

[dreamsat]

Thank you for your fast answer. I will try it and let you know if it works. Do you know if it is maybe possible with another solution to concat 2 columns and save it in another column? Maybe LogicApps? Or a remote event receiver?

[Pstork1]

YOu can easily take the values from two columns and concatenate them to update a thrid column.  But I'm not sure how that relates to the topic of your original post.

[dreamsat]

Im using flow to do the concat of 2 columns and add the value in a third column. But I do not want the column "modified by" will updated to the system account. That is ugly.

[Pstork1]

Take a look at the blog I posted.  It explains how to make changes that won't cause the system to update the Modified By or Modified metadata.  In general any modification will trigger those changes.  If you make the change using some particular flags via REST call you can keep the system from doing that update.  Its all in the Blog, but there is no easier way to do it.

[v-bacao-msft]

Hi @dreamsat ,

Thanks to the method provided by @Pstork1 . I did the test on my side. If you want to change the Modified by to the Creator after updating the specified item with Update item action, this method is feasible.

It's worth noting that even if we change the Modified by using the HTTP request, the version history will record every action done on the item.

This method can change the user of the final Modified by, but the version history cannot be changed. If you don't mind this, this method fits your needs very well.

In addition, you mentioned that the two field values are integrated into other fields. Please refer to the following image:

Please take a try.

Best Regards,

[Pstork1]

Actually, the point was that if you use an HTTP request to do your modification and include the 'bNewDocumentUpdate' tag set to false the system will not record it as a change. The idea was not to change the Modifiedby back after making the changes, but to replace the update Item actions with an HTTP request set this way.

[dreamsat]

What is the differance between these 2 solutions? I see the solution of @v-bacao-msft is doing first the normal update item activity. This activity will be executed by the owner of the flow. After this there is the http request activity which will be modified the field "modified by". The solution of @Pstork1 is everything in 1 activity. Update the list item and update the field "modified by". Am I correct?

[Pstork1]

They are essentially the same solution.  The point is that if you use the regular update action the system will change the modified by attribute when it saves a new version.   YOu can then update the item using a custom HTTP REST call to change that attribute without causing another automatic update. OR, you can make all your changes using the HTTP REST call.  If you do it that way a new version isn't created and the system doesn't try to set Modified By.  If you want a new version created use the two step process.  If you just want to update the metadata without triggering a system update then do it all in HTTP.

The other side effect that should be noted is that if you use the built in update action and you are using a trigger that fires when an item is modified you may get another run of the entire Flow.  This depends on timing, but often happens.

[dreamsat]

Hi @Pstork1 @v-bacao-msft , I implemented your solution but I see some loop. Because the flow is triggered by created a new document or modify the metadata I see some loop in the flow. The flow starts initial and modify the field "modified by" and will trigger the flow again. It will modify again the field "modified by" and will trigger the flow again, etc etc.

Is it possible to update "modified by" once and not trigger the flow again? Maybe when I set 

bNewDocumentUpdate to true?

[Pstork1]

Setting bNewDocumentUpdate to false when doing the HTTP update is what keeps it from firing the modified trigger again.  Did you replace all the update actions with the HTTP action?  That's really the only way to keep if from firing the trigger again.

[dreamsat]

So do I need to set it to true or false to prevent triggering the flow again?

[Pstork1]

It has to be False if you don't want to trigger an update.

[dreamsat]

It is already have the value false. And yes I have first an action where I modify the metadata like for example Title. And then a second action (send http request to sharepoint action) to modify the metadata "modified by". Why do I have this loop?

[Pstork1]

The loop is firing beause of the other update action. To prevent that you ahve to do all the updating via the HTTP request with the value set to false.  Otherwise the regular update will cause the trigger to fire again.

[dreamsat]

But before without the http request action there was no loop. Before there was also an action to modify the title. The flow was not looping.

[Pstork1]

The update loop doesn't always happen and tends to be based on timing.  But the HTTP request with bDocumentNew set to false is specific designed NOT to trigger as an update.

[dreamsat]

Hi, on this blog this guy is say when you set it to true there will come no new version:

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistite...

Is he wrong?

[Pstork1]

There are conflicting reports on different Blogs, but after doing some testing of my own it looks like you are right and it should be set to True if you want to avoid the update Loop.