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:
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.
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:
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.
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.
1) A screenshot of the Approval flow:
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.
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.
Dive into the Power Platform stack with hands-on sessions and labs, virtually delivered to you by experts and community leaders.
Watch Nick Doelman's session from the 2020 Power Platform Community Conference on demand!
Check out the community blog page where you can find valuable learning material from community and product team members!