Preventing Recursive Workflows in Power Automate Using Dual Status Fields

When building approval workflows in Power Automate, one of the most common challenges is preventing recursive execution. A flow updates a SharePoint item, the update retriggers the flow, the flow updates the item again, and before long a simple approval process becomes difficult to manage and troubleshoot.

While building a multi-stage / multi-year approval process, I encountered this exact challenge. The solution was to separate business status from workflow state by implementing two status fields with distinct responsibilities. The workflow state status is used to determine if the workflow should run again.

This approach improved reliability, simplified troubleshooting, and prevented unintended flow execution.

How It Works

The workflow was triggered whenever an item was created or modified within a SharePoint list:

1. User submits a request.

2. Flow starts.

3. Approval actions occur.

4. Flow updates the item based status, through a switch control.

5. Status is updated at the end of the switch case.

The problem occurs when the flow performs updates to the list item.

Because the trigger is configured for item modifications, every update performed by the flow has the potential to trigger a new instance of the workflow.

Without proper controls, the process can repeatedly trigger itself and create unnecessary executions.

The final design uses two status fields.

• The first field is visible to users and represents the current business state of the request.

• Examples include:

  • Draft

  • Submitted

  • In Review

  • Approved

  • Rejected

  • Completed

This field exists purely for business purposes and user communication. For this project this field is controlled by the UI on the form, when the user clicks a button to move to Engineering it will change the status.

• The second field remains hidden from end users. This is purely a system field that tracks the workflow.

This field stores information used exclusively by the workflow.

• Examples include:

  • New

  • Draft

  • Submitted

  • In Review

  • Approved

  • Rejected

  • Completed

Because this field is controlled by the flow, it becomes the source of truth for automation

When a new item is created, the Item status is set to Draft, and the workflow status (called Last Status) is set to New. When the flow runs it has a trigger condition in the settings, this condition looks at the Last Status compared to the Workflow Status, if the two status are NOT the same value then the flow will run. At the end of the Status based switch case the Last Status will be set to equal the value of the current status. This will insure that when that update is made and the flow starts again it will see the two status fields as being equal and not run again. The status field on the form is controlled by button approval, so the ui changes will set that value through the Power App.

One of the biggest lessons from this project was the importance of state management in automation design.

Many workflow issues originate from mixing business information with system logic.

By separating those responsibilities into dedicated fields, the workflow became easier to manage, easier to support, and more resilient to future changes.