cancel
Showing results for 
Search instead for 
Did you mean: 

Disable Event Firing when Flow updates a SharePoint list item

Add a feature that will allow flow to disable event firing when updating a SharePoint list item, so that the Flow doesn't get stuck in a loop. Currently if I create a flow with a SharePoint list trigger when item is created or modified and have the Flow update a field in the item the loop gets stuck in a loop. One workaround is to add logic to check if the field(s) still need to be updated and if not then don't update the item but even in that case the flow will be triggered twice. It just makes sense to have an option that will allow Flow to update an item without triggering an event that will cause the same Flow or another Flow to run against the item again.

Status: Declined

Hi all,

 

After thoroughly reviewing this idea, we have decided not to proceed with this idea for a couple of reasons.

  • SharePoint events are no longer event receiver based and are performed using webhooks or polling where applicable
  • Other Office 365 applications and internal systems like auditing may and will rely on such changes like updates to items, files and other entities in SharePoint

However, that said, we understand the crux of the issue which is to help avoid loops. We will work with the flow team to come up with a generic model/pattern that applies across data source/connections for similar scenarios.

 

Thanks all for your input and please submit/vote your ideas as we are actively monitoring the ideas forum.

 

Thanks,

Chaks

Comments
Level: Power Up

I find the declined reason hilarious, how could they reject this request when so many people is reporting the issue giving good explanations about why is a problem, just look at the way old Workflows use to work, they were self-aware and didn't have this problem, if it is an architectural problem then fix it, is so irresponsible and abusive to force people to spend two Flows runs (as minimum) when having these type of scenarios, for example there are approval processes where you may need to update the same item in different actions of the Flow, so you will end with a lot of wasted executions, the most concerning about Microsoft staff decisions is that this issue was identified since the bare beginning of MS Flows release, if you want to truly help without spending lot of effort on big backend changes then just handle the validation with internal Flows that don't count for the our Flows consumption, at the end of the day we are just asking for a setting in the Update item/file action to label that action to not trigger additional instances of the Flow.

Please take this matter with the respect it deserves.

Level: Power Up

I find the declined reason hilarious, how could they reject this request when so many people is reporting the issue giving good explanations about why is a problem, just look at the way old Workflows use to work, they were self-aware and didn't have this problem, if it is an architectural problem then fix it, is so irresponsible and abusive to force people to spend two Flows runs (as minimum) when having these type of scenarios, for example there are approval processes where you may need to update the same item in different actions of the Flow, so you will end with a lot of wasted executions, the most concerning about Microsoft staff decisions is that this issue was identified since the bare beginning of MS Flows release, if you want to truly help without spending lot of effort on big backend changes then just handle the validation with internal Flows that don't count for the our Flows consumption, at the end of the day we are just asking for a setting in the Update item/file action to label that action to not trigger additional instances of the Flow.

Please take this matter with the respect it deserves.

@Chakkaradeep #MicrosoftStaff #GiveValueToUserVoice

Super User

You do not spend a flow run using conditional trigger, this system works very well and fairly easy to setup, the same examples can be used again and again. I myself create a SLT column "StartFlow" default value "Yes" in my flow the first thing i do is set it to "No" after that the flow only runs again if i actually update it to "Yes" which i do via buttons on my form if required. The condition is easy:

 

@equals(triggerBody()?['StartFlow'],'Yes')

 

Flow is de-coupled from SharePoint where Workflow as tightly-coupled in this scenario it prevented you from running the same workflow 2x at the same time.

Level: Power Up

Thank you @Gristy, you are right, the conditional works well when applied directly to the Trigger settings, the feature is a little hidden though, I noticed it didn't spent additional runs for the validation, it did a check to skip, as far as I know checks don't count for the consumption so this solution is very good.

Level: Powered On

I have a large amount of users and it is difficult to make sure they utilize the yes/no column properly since it does not default back to yes each time.