No loop work around suddenly not working..validateupdatelistitem

[damooji]

My team had implemented many flows using the validateupdatelistitem endpoint starting last year to prevent loops, however we noticed recently these flows have begun to loop.  Anyone know if there has been a recent change or what could be the cause? I can only assume there must be have been some update that would cause something that was working to suddenly not

[Pstork1]

I'm not sure if there has been any change that would cause this effect, but the easiest way to prevent looping on updating records is to use a trigger condition on the modified trigger that triggers the flow.  There are a variety of ways to do that, but one of the most effect is to use a service account to run all the flows that might cause updates and then set the trigger condition to not fire if the Modified By field is equal to that service account.  Here's an article that explains how to create such a trigger condition.

How to avoid infinite trigger loop in Power Automate (tomriha.com)

[damooji]

Yea, unfortunately my organization will not give my team a service account. Trigger conditions would be hard, given the flow needs to kick off any time a record is updated.

[Pstork1]

Trigger conditions can be done different ways.  Modified By is just the easiest.  You could also add an extra field to the fields you are changing with the flow and set the trigger not to fire when that field is set to a specific value.

[damooji]

We tried using another column, but not sure how that would allow a record to be updated multiple times with flow triggering on each update. Basically, the requ is, anytime a user clicks edit then save, flow should kick off. If we had another column, say called "triggerFlow", default set to yes...and trigger condition was if it equaled to Yes, then on update changed it to No, loop wouldn't happen...but next time the record is updated the flow won't kick off.

I just did a quick test btw on my personal environment, sure enough the looping is happening with validateupdatelistitem...so I can only assume there must have been some changed pushed? Or perhaps I need to change the order of how the columns get updated.  Link that was referenced for this last year: http://johnliu.net/blog/2019/2/flowninja-hack-78-modifying-modified-by-and-modified-time-with-micros...

[ScottShearer]

@damooji 

Here is a link to a blog post that shows another method of preventing infinite loops.

[Pstork1]

Did you notice the update in John's blog saying that you should use bNewDocumentUpdate: true instead of false to avoid creating new versions.  The change that happened may be that any new version is considered a modification even if done by REST

[damooji]

@ScottShearer  - while this is a solution I can say I've never seen, and will keep on hand, at the moment I'm trying to figure out a if there might be a simple change/update that can be done resolve this, or as to why the flows have recently started looping.  We have over 60 flows using this.

@Pstork1 I did - and tried both true/false, loop still happens.

One of our users claims he noticed the loop starting around Nov. 12th.  I'd assume some change occurred impacting the validate endpoint, but would also think if this was the case..there would be posts about this online already. Just can't seem to understand why these flows were working w/o loops for over a year and suddenly are.

I've tried rearranging the json, tried changing the date/time format with no luck.  I may have to use Scotts suggestion, but hoping there is reason for this or maybe there is a fix MS will make soon? IDK at this point..

[Pstork1]

If you have tried it both ways then, clearly something in the backend process has changed that invalidates that workaround.  You could open a service call and ask MS if its a bug.  But I suspect your only choice now is to either find a way to implement a trigger condition that will weed out the automated update modifications or add logic that will terminate the flow if it detects such an update.  Scott's suggestion is one relatively easy way to accomplish such a trigger condition.  A service account is another.  BTW it doesn't have to be a service account.  It just has to be a user that never makes manually updates on that list.