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
Regular Visitor

Dear @Gristy, please give us a list of these easy ways. Thanks

Regular Visitor

@marpio check my post from ‎03-11-2020 02:04 AM. It's a way, though not an Easy one.. 

Kudo Collector

There is no easy, intuitive way around this, that's the problem, and that's why this thread still gets posts.

 

Maybe it is reflective of different product teams within Microsoft working in silos, and not actively working together on a solution.

Super User

@marpio you can use trigger conditions once you have got it working once it's very easy just use the same pattern and copy and paste

 

I generally use a service account to run my flows so just do not run the flow of they are the editor in SharePoint.

 

The functionality will not change that is currently there 

New Member

When this idea was originally posted, and declined by Microsoft, they promised to share some recommended approaches to curtailing this behaviour in PA. I've been unable to find anything that's been produced in the two years since.

 

I have found a number of different approaches for workarounds - and thanks to those who have contributed these ideas - but as others have said, it still feels like a sticking plaster over a situation that's perfectly logical if you are a programmer, but not if (like me) you are a mere mortal just trying to get a flow up and running.

 

Basically, we need a trigger along the lines of "if it was flow that caused the update to sharepoint, don't trigger the action again". That would be intuitive.

 

The closest I've come so far to finding a generic solution has been the one that compares the modified timestamp against a hidden column that flow updates when it has made a modification and if it is within a defined time period, the flow doesn't run. But I easily get lost in an expression that's about 6 paretheses deep (as I said, I'm mortal). Its far from easy.

 

Any better suggestions folks?

 

 

Super User

Just use a custom column called Startflow and set it to yes and no and do a trigger condition on that.

 

You can also use a single account to run your flows and compare if the editor is that account.

Advocate IV

@Gristy- Your suggestions will work but there is a new functionality called "Trigger Conditions" which fixes the issue. 

Super User

I did not say use a condition etc.

 

I was talking about trigger conditions as I have been for a several posts it's super easy 🙂 I use them every day

Advocate IV

LOL - You have to write posts like you write code. Zero ambiguity. 

Advocate IV

@AndrewMoore  - The answer is "Trigger Conditions" - Just Google the term and you'll find some resources to get you moving in the right direction.