Flow update to SharePoint list item fields triggers the Flow to fire again

[JJ_in_atlanta]

We often use sharepoint designer workflows to set list field values that we will examine later in the workflow, when the item is updated by the user at a later time.  I just tried to to that with a Flow. The Flow triggers on item Creation or Edit, and then modifies several fields in the same list item.  I am seeing that the flow is actually being triggered lots of times - it appears to be in a loop where the updates it makes to the list item triggers the Flow again, makes more updates, which triggers it again.  Is this expected behavior? If so, is there a way around this?

[v-yamao-msft]

Hi JJ_in_atlanta,

I assume that you are using the trigger “When an item is created or modified”. This trigger will be triggered whenever an item is created or modified. So when your users update fields in the list, it will be triggered.

Not sure with your scenario. You may try to use the trigger “When an item is created”, then the flow won’t be triggered when an item is updated.

While if you want to be notified when a certain field is updated, you may consider to add a Condition in your flow to filter the flow runs.

Hope this could be a reference for you. If you need more help, please feel free post back.

Best regards,
Mabel Mao

[JJ_in_atlanta]

Thanks for your reply, though it didn't address my question.  My flow triggers on item Create or Modify, which is what we need it to do.

What it does is reads the value of a field and then updates the value of another field in the same list item.

When it updates the value of that other field, the flow is triggered again because it fires On Modify - which it needs to do so that when a user modifies the item, it can update that other field if appropriate.

The issue is that when the flow updates the list item, the flow detects this item modification and so triggers itself again, and again, and again. Is this expected behavior? Is there some setting on the flow that I can set that says "don't let item updates made by this flow trigger this flow again"

thanks

[Wondertimo]

Has this been fixed? 

When we were able to do this with C#, it was easy, just added base.DisableEventFiring() and then modified the list item programmatically. 

If this problem still persists, Flow is useless

[v-yamao-msft]

Hi JJ_in_atlanta,

Thanks for updating.

The situation you are having would cause Microsoft Flow in a loop. It is a default behavior that when a list is updated, flow will detect it as a modification, so the flow will be triggered again and again. I am afraid that there is no workaround currently.

I will help confirm this issue on my side.

Best regards,
Mabel Mao

[SavaricTheSpear]

Hi Mabel,

I want to bump this thread.  I agree with the OP, this severly restricts what I can do with Flow.  I have an identical use case.  There might be some folks out there that need the recursive triggering as well.  The more common case I find is run the flow one time when an item is updated, to allow me to control values on that same item (by updating it within the flow).

Flow needs to let us disable this recursive trigger behavior.  Please escalate to the development team.  I'm going to try to figure out how to do that myself as well.

Thanks,

Harry

[Anonymous]

I also wanted to add another +1 for this.  This prevents me from being able to perform a true sync between Sharepoint and an external API.  I'll take any work-around available!

[efialttes]

I guess if you add a condition after the trigger, maybe you can minimize the number of times the trigger is invoked.

I mean, as a temporary workaround.

For example, if the item is modified by the Flow Owner, then skip the rest of the Flow action Blocks.

Unfortunatelly, I haven't tested such workaround yet.

[Anonymous]

Hi JJ_in_atlanta,

I reckon this is still an issue because i haven't seen any comment that says it has been resolved.

Not sure if this would help, but a possible workaround from the top of my head might be to:

1. Add a hidden field which would hold the same value as the field that is updated

2. Before updating the field, compare the value read from the original field to the value in the hidden field and only perform the update if the values are different (update the value in the hidden field at the same time)

I am hoping the above would reduce the number of updates to the field.

I may be in the same dilema soon because I just started working on a simialr trigger but a different scenario yesterday and am yet to test.

[Anonymous]

I added a condition that checks if the modified and created date are within 2 seconds of each other, and then had the process go in two different directions based on my custom connector.  That semed to work.

[Anonymous]

How would you manage that with the Flow language?

@equals(triggerBody()?['Created'], triggerBody()?['Modified'])

If created equals modified +- 2?

[Anonymous]

@lessOrEquals(triggerBody()?['Modified'], addSeconds(triggerBody()?['Created'], 2))

I had once instance where having a 1 second difference wasn't enough.  2 seems to be the magic number here. 

[Anonymous]

Thank you very much. I had no idea Flow was capable of less than or equal to.

[Anonymous]

Glad to help!

The interface is weird:  It will give you the boolean syntax related to numbers, but only if you save and reload the page with an integer or time field has been added.  

[JJ_in_atlanta]

That won't work in my use case - each time a user edits an entry, we need to check for changes and possibly alter some list item fields - it isn't just a one-time change.  So, comparing against the created time won't help.

[daniel667]

Same problem for me, quite common scenario it seems.

Guess i could fall back to C#, but feels like you should not have to do that for such a simple task.

+1

[efialttes]

Hi

@v-xida-msfthas published a workaround in the following thread 

https://powerusers.microsoft.com/t5/General-Flow-Discussion/Flow-running-thousands-of-times-on-SP-qu...

Unfortunatelly, this workaround is not universal but targeted for a very specific scenario, in which the result of item update is also evaluated in the Flow meaning it is executed twice instead of entering an infinite loop

These kind of "condition based" workarounds are the ones i was referring in my previous post: "I guess if you add a condition after the trigger, maybe you can minimize the number of times the trigger is invoked.I mean, as a temporary workaround. For example, if the item is modified by the Flow Owner, then skip the rest of the Flow action Blocks."

I totally agree it is a huge limitation in Microsoft Flow. Let's hope Flow architects will find a solution to fix it. 

[Bee]

Glad I found this post becasue I thought I did something wrong when my flow kept looping. Still no solution after all this time. I want to start using Flow instead of workflow, but I had to go back to workflow everytime because of limitations such as this one.

[FocusAdmin]

We have documents that need to be altered if they are rejected.

They go through 3 different approval processes - when they are declined or accepted the message is stored on the list as a comment from each approver. 

The list gets updated and the trigger starts again - but I need this Modfied trigger as the user will modify the document to make changes to go through the process again.

Am I doing something wrong, maybe using the wrong Flow ?

[Anonymous]

Can you provide more details on how you accomplished this, please?