How to differentiate if a SharePoint list item was edited manually or by a flow?

Question

I have a SharePoint list on which a flow operates. The flow is triggered by new or edited items.

Problem: The flow itself updates the item from which it was triggered. This, of course, triggers the flow again. If I took no measures, the flow would trigger itself again and again.

I took the following measures to prevent permanent self-triggering:

• Just before performing the modification of an item in the list, the flow will check if the fields inside the item which were meant to be changed already hold the changed values.
• If so, the change is skipped and the trigger is not issued.

This has two drawbacks:

• The flow is at least triggered twice per item. The first time when a user is doing an edit; the second time after the flow itself made its updates
• To check the necessity of doing the edits within the flow, all calculations and data work has to be done as if it were for real. And as I'm parsing other lists to do the calculations, it means some data and processing load which is essentially unnecessary.

I currently don't know how to circumvent that behaviour. And I'm planning to implement another flow which frequently does edit a lot of items which would trigger the first flow many times. I'm in need to find a solution to this.

I thought of different possibilities but lack knowledge about feasibility. Every solution I think of brings up another problem:

1. I could add a column in which I code the ID of the flow which has edited the item last. Let's say 1 for the triggered flow, 2 for the regular flow. The triggered flow should bail out on 1 and 2, i.e. should only operate on user actions. But I know of no means to reset the ID to let's say 0 after a user edit. Pre-filled columns only work on new items not on edits. Calculated columns can't be written by flows, etc.
2. Could add a timestamp which is set only by a flow. The next execution of the flow could check if the date of the flow matches the last edit date. But this would be rather imprecise, the times will still differ and I can't rule out accidental near-simultaneous edits from user and flows.
3. I think of other properties in the edited item which could identify the source of the edit, but I don't know of any. The flow runs with my user ID, so every edit seems to be done by me. Currently I don't have access to other accounts.

Any ideas how to make idea #s 1 to 3 work, or even a #4?

Addendum: I thought I had one solution:

1. I add a column, let's call it EditByBot to my list, most likely an integer number. I don't hide that field, so it will appear in add and edit form.

2. I let the default value of that column be 0.

3. I add a rule to the column checks of that list (I don't know the proper name for that setting within list settings, over here it has the name Überprüfungseinstellungen). The rule says, the column EditByBot has to be 0. The Rule can be formulated as

   =([EditByBot]=0)

4. Any flow operating on a list item will set that column to a number other than 0 identifying the flow.

Unfortunately the edits of my flow are subject to the same rule checks as an edit in a form.

Answer 1

There are lots of solutions described here Disable Event Firing when Flow updates a SharePoint list item But most seem to be very cumbersome, involving a second list or using creepy REST functionality.

Now I found a solution for this cretinous turing test. And I begin to like, what I found.

But it depends on versioning of the library/list. Nevertheless it is a solution which doesn't need user interaction.

I try to explain the principle before describing the method I found. The principle consists of two things. Having a property which is special to an edit done by machine vs. something done by humans. It is easy to incorporate something which is only done by the machine. I.e. a hidden column, which is updated by a flow. But it is absolutely not easy to incorporate something which is done only by humans. A human editing an list item may change any field which is not hidden. To monitor voluntarily human edited columns one has to have a shadow copy of every column. This is ridiculous and connected with similar hassle as my initial solution with trying to determine if an edit is necessary or not.

But here comes the ruse. I can have something which is changed everytime, regardless if done by human or by machine. The rest is logic combination. If the field A is changed everytime and B only when the machine did an edit, the only remaining task is to tie those events together.

Here it comes:

1. Enable versioning for the library or list

2. Add a number column

3. Program your flow

4. Add a column (number), let's name it VControl here, to the list

5. Set the default value of VControl to 0.

6. Hide the column. Of course this will not prevent savvy users from editing it, but if that's the problem, don't use SharePoint at all.

7. At the beginning of the flow add a comparison of the VControl and the version field of the triggering item. You have to convert the version from string to int. e.g.:

   int(triggerBody()?['{VersionNumber}'])

8. If version is less or equal VControl, abort the flow.

9. If not, do what you want to do in your flow.

10. When you do the modifications of the item write this into VControl:

add(int(triggerBody()?['{VersionNumber}']),1)

That's all. After any edit done by a flow, VControl will be the same number as version. After any human edit the version will be higher than VControl. Every flow will be started at least twice, which is very common for most solutions. But the execution of the second start will be stopped by a simple condition instead of a complicated rambling.

Bonus: Probably the test can be implemented inside the trigger conditions, which can stop the flow before it starts.