Flow running twice per edit on SharePoint created/modified trigger

[pzigs]

Hi - I currently have a problem with my Flow where it runs twice with the same initial conditions, with a slight time delay (20ish seconds), in almost all cases.

Example of the repeats - this should be 4 runs, but is instead 8:

The flow uses the following connections:

automation@ is a service account so we can track when the Flow makes edits vs a user. Notice here that the only SharePoint connection is through the service account, so whenever an edit is made by the Flow, it is made by automation@.

Here is a general overview and explanation of the flow:

1. Trigger action. Checks for a modified item in an Infopath Form Library that has SharePoint content approval set up
2. Can be ignored - this will usually be False. This checks to see if the service account made an edit, and terminates the flow if so (to prevent inadvertent loops).
3. Get the filepath of the XML using Get File Metadata, as this is not returned with the trigger action.
4. Can be ignored.
5. Can be ignored - we have examples where this is False.
6. Get Access Token - We use some HTTP calls to SharePoint REST API in some of the minimized conditions. This gets our access token as this was built before the Sharepoint HTTP action was available.
7. Can be ignored - we have examples where this is False.
8. Can be ignored.
9. A large switch case in which emails are sent from a shared mailbox based on the status of the item.
10. Once all automated actions are finished, HTTP calls a reusable service flow which approves the item and makes it visible to all users. That service flow is:
    1. HTTP trigger
    2. Get file metadata using path (for E-Tag)
    3. Set content approval status > Approved (using automation@ account)
    4. Return status code 200

Thanks for any help anyone can provide. I am at my wits end here - we have a similarly complicated Flow on a different Form Library that uses the same building blocks (HTTP calls, service account, content approval, email notifications, etc.) and are not having the same issue. The SharePoint version history shows only one edit. I have already tried triggering the flow off and on again, and have also exported and re-imported.

[v-xida-msft]

Hi @pzigs,

Could you please share a screenshot of your reusable service flow (The "Call Approval Flow" action of your first flow calls)?

I think this issue is related to the "When an item is created or modified" trigger of your first flow and the "Set content approval status" action of your reusable service flow (Second flow).

The "When an item is created or modified" trigger would be fired when there is an item is created or modified within your SharePoint list. When an item is modified in your SharePoint list, your first flow would be fired. When your first flow executes the "Call approval flow" action (Step 10), your second reusable service flow would be fired. When your second flow executes the "Set content approval status" action, your SharePoint list item would be updated and then your first flow would be fired again.

The user @DS1 has faced similar issue with you, please check the following thread:

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

You could consider take a try to add a custom Yes/No type column (UpdateFromSeusableFlow, default value of it is No) within your SharePoint to check if this update is from your second reusable service flow. Within your second flow, set the UpdateFromSeusableFlow field set to Yes using a "Update item" action. Within you first flow, add a Condition under the trigger, check if the UpdateFromSeusableFlow field is equal to true, if yes, do nothing.

Best regards,

Kris

[pzigs]

Thanks for your reply. As I was writing up a reply I found the problem - I have detailed it below for anyone else who may come across this. I believe it is still esoteric enough behavior to be classified as a "Glitch", but I will leave that for the Microsoft team to decide.

Short Version: You are correct in that "When item is Modified" trigger is triggered by an item being Approved. The issue in this case came from which user is marked as the "Editor" when an item is approved.

In SharePoint, when an item is Approved, the approval step is not recorded in the version history. Rather, the item is approved and the latest version is marked as Approved, and the "latest editor" is marked as the person who made the last field edit to the item.

In Flow, however, the "approval" edit triggers the "Modified Item" trigger with the original editing user (as also shown in SharePoint), assuming the Flow does not make any changes. If the Flow does make changes, then the item will show the latest editor - the Flow account - as the item's modifier. Therefore we are unable to use our Loop check without editing the item within the Flow. This is a significant limitation, as it means the "Modified" column in SharePoint must always read the account name of the Flow account if content approval is used. This is regardless if we use a service account, as I describe below, or a "flag" operator, as recommended in the above reply. I believe the correct behavior should be that Flow should not trigger on an Approval step - manual or otherwise.

Detailed Version:
 

1) A screenshot of the Approval flow:

Approval Connections

 Service Flow - Approval

Notice - automation@ is used as the account approving the item.

2) Expanding out the "Loop check" in the main flow that should solve this issue:

However, it does not - because, for some reason, even though Automation is the account that "Approves" the item, it is not marked as the Editor in the next trigger, unless it makes an edit to a field in the item.

3) Screenshots of the duplicate triggers. Notice the "Modified By" is the same, even though the "Approve" step was done by Flow, and the SharePoint version history showing one "Edit" by design, even though Flow triggers differently.

Edit 1Edit 2Version History

Successful Workaround (verified): Make sure that the Flow always makes an edit to an actual field in the item. Then, it will be listed as the latest editor in the version history, and will be appropriately picked up by the Loop Check.