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.

Level: Powered On

Almost 2 years on and this issue is STILL killing us.  The infinite loop issue is a really bad oversight by Microsoft.

 

I still don't understand why this was declined.  The related idea to only trigger when a particular field is updated might work in some use cases, but what about the use case where we want to update a list item/file based on ANY update made to the item/file?  We'll still have the infinite loop problem.

 

MICROSOFT PLEASE FIX THIS ISSUE, IT IS HURTING US!!!!  Weird workarounds in SharePoint are just not acceptable, especially after so long.  @Chakkaradeep .  

Super User

There are plenty of ways to prevent the infinite looping so nothing will be changed

 

You could use a service account and just exclude that account on the trigger conditions.

Level: Powered On

@Gristy Thanks for the comment and am exploring that as a workaround, however not every organization's IT dept will gladly create a service account at the drop of a hat.  Comments history in a multi line text field is not an option, because the business user has explicitly state they don't want version history turned on.  The JSON API options are also clunky and hard to get right, especially when there are a very large number of fields that need updating.  Trying to explain to business users why this issue exists is challenging.

Level: Powered On

The comments here are funny. This is just how it is, nothing will change. Plenty of "work-arounds". All new users will have to struggle though this, and just learn the hard way. Just figure it out. 

Level 10

C'mon Chaaks…  obviously this is something that needs to be addressed and fixed.....  Just because it is hard is not a reason not to do it...  otherwise we would still be staring at green screens and using punch cards!