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

@Pieter_Veenstra, the above screenshot is just to show MS about the infinite loop. It is a simple logic just for demo purpose of the loop.

 

1. A user enters a new schedule in the calendar list, set the NEW schedule radio button status to "Yes". If it is a "Yes" do nothing. 

2. Another user edits number 1 then set the NEW schedule radio button to "No". If it is a No then proceed to update item -  this is where the endless loop.

3. When the flow is done processing number 1 or number 2, "Terminate" flow but it doesn't work.

Power Automate
Status changed to: 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

Frequent Visitor

This is.. very disapointing and will impact if we implement flow moving forward. Not sure why third party workflow engines, like Nintex for example, do not spin off infinite loops but MSFTs own product does.

 

I understand that SP has moved away from event recievers, but I do not understand how this prevents Flow from recognizing that a previous Flow run updated an item? 

 

I'm confused on this second point, if an auditing system relies on items updating, wouldn't an item being modified indefinitly cause a much larger issue? 

 

Also, we are still burning up twice as many flow runs as needed to avoid an infinite loop. It will come to a point where I will need to explain to a client that we will be paying for extra flow runs because Microsofts "Best Practice" solution requires to run a flow twice to prevent users inboxes from being filled with approval emails. 

 

At minimum we need to be able to conditionally trigger a flow without using a flow run if the item does not meet that condition. (When an item is created or modified, and column "RunFlow" is equal to "Yes")

Power Automate

@pmcopeland We are indeed looking into ways to handle the issue around flow runs and also be able to conditionally trigger a flow - they are already top ideas voted here in this forum. The infinite loop issue would exist in Flow with any other data source that handles generic update/modified event trigger as well and we want to ensure we do the right thing that accrues value across all connectors. 

Advocate V

@Chakkaradeep 

I am also disappointed and I got with @pmcopeland:

What means "declined" exactly? You simply will do nothing about it but only show us a big(?) workaround in a few weeks to handle this basic behavior?

Or do you will provide at least a simple and small update to make very simple workarounds without need of 2 or more flow runs?

 

This problem is not about fancy flow stuff. This problem occurs very often and very simple when you have a trigger which triggers on a updated sp list item (new or modfied trigger) and then start an approval, and after approval the flow write feedback/status (or anything else) back to the item. You will have at least one following (sometimes infinite) trigger again.

 

We discussed it and I show simple scenario on page 13 and 14 here in the comments:
https://powerusers.microsoft.com/t5/Flow-Ideas/Disable-Event-Firing-when-Flow-updates-a-SharePoint-l...

 

This problem (I will not call it idea or feature, it is simply a design/technical problem) is top voted here. And we don't want to spent 2 (or more) flow runs when only 1 is needed. Also, we don't want complex workarounds for such a simple scenario like a updated sp list item which triggers the modified-flow-trigger which starts an approval and write his approval-state back to the item after approval decision.

 

(Or I miss the solution here on the comments to solve the discussion on page 13/14)

Advocate II

I think what @Chakkaradeep means is that Flow/LogicApps need to add a concept of ignoring triggered items on certain conditions in a general way. Any source having a trigger would fire that trigger when you update the item, which for the source system is good for auditing scenarios.

 

For SharePoint in particular you can workaround by using SystemUpdate as I've blogged, but this is very SP specific, and by using SystemUpdate you sort of miss a version trace of the update as well - which might not be what you want.

 

So it's a simple scenario, which is harder to solve in a general technical way.

Advocate V

@Mikael_Svenson : I think you just want to help, but sorry, I am still not satisfied. 

- This is a top10 voted idea. Top 7 actual!

- on page 13 and 14 you see how easily you run into this problem

- And we get no solution for it! The idea is declined. 😞

 

As I said before, the "workaround by using SystemUpdate" is very kind of you, and you must be very SP skilled to come to such an idea. But for me it reads more like a glitch like a supported solution. Perhaps it is not working anymore on the next update. Also a bit complicated. And also we have Versioning on this SP Lists, so we need "version trace".

 

I hope @Chakkaradeep and the Flow devs will come up with a real solution.

 

Power Automate

@teqs I would separate the two things:

1. Fixing the issue where updating an item triggers the same flow

2. Ability to disable event firing when updating a SharePoint list

 

Problem #1 is not unique to SharePoint actions. This should be a separate idea and it would be great if you can start a new idea as it would help us collectively come up with a solution if any to manage this particular problem.

 

Problem #2 is what this idea is about. This is specific to SharePoint. And I outlined the reasons why we had to decline this idea.

 

I hope that helps.

 

Thanks,

Chaks

Post Prodigy

What would really help is if the "problems" you accurately described were addressed in a way that would make them not problems for the thousands of users who wish to build simple workflows (ones that used to take a few minutes to create using previous tools). Soliciting ideas from customers, then spending time and effort arguing why you’re declining the customer's top-voted ideas, is not particularly helpful to the customer. Nor is suggesting the customer must now submit another new idea, particularly after the original one was dismissed with a “declined” banner across the “idea” (which is really a “problem” as you even described it as, not an “idea”).

 

It is understood that there is a process around evaluating and adding new features, and that features must be implemented in a logical fashion, however it is also understood that fixing this and providing your customers a way to do what they need to do is currently well within your technical capabilities and that we must do without for the sake of ideological purity.

 

I can’t even make the non-technical leaders I work with believe that this simple thing cannot be properly accommodated by Flow. Luckily I have 16 pages of customer feedback I can provide them to demonstrate.

Kudo Collector

"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."

 

That's a cop out, and quite frankly seems a lazy way of addressing an issue that has 16 pages worth of comments.

 

This suggestion has a large amount of votes and needs to be addressed.

 

Once again, Flow, as a business tool, is not readily supporting BUSINESS scenarios, and at the same time, causing headaches with quotas.  That is grossly unfair on two fronts.

 

Someone has come up with a workaround solution (and a big thankyou to @Mikael_Svenson !)  Maybe Microsoft could do the same by taking their lead and packaging/adding a similar actions (i.e. an action that supports ValidateUpdateListItem with the ability to set bNewDocumentUpdate) to the already badly lacking list of SharePoint actions in Flow, instead of throwing their hands up in the air and saying "sorry, it's too hard".