BuilderVault
FreeIntermediatePower AutomatePower AutomateSharePoint

Run a flow only when status changes

Learn how to use Power Automate Run a flow only when status changes with practical Power Automate guidance, implementation steps, common mistakes, troubleshooting, and related BuilderVault patterns.

Power Automate Run a flow only when status changeshigh intentIntermediate

What this pattern solves

Power Automate Run a flow only when status changes is a practical BuilderVault pattern for makers and developers who need a repeatable way to handle run a flow only when status changes inside a real Microsoft business app. The goal is to move past trial-and-error and give the builder a clear structure they can adapt to their own screens, flows, lists, tables, or environments.

Use this page when you are deciding how the pattern should work, what supporting data or permissions are needed, and what should happen when the happy path fails. The notes below focus on implementation fit, common mistakes, troubleshooting, and internal links to adjacent patterns so the build stays consistent.

Search intent

Help a Power Platform builder understand when to use Power Automate Run a flow only when status changes, how to implement it, and what mistakes to avoid before using it in a production business app.

Problem

Flows that trigger on every item update can send duplicate emails, start repeated approvals, or waste run capacity.

What the finished pattern should include

  • The flow has a clear trigger, scoped actions, tracked outcomes, and an exception path.
  • Notifications or approvals tell users what happened and what action is required.
  • Support owners can review failed runs without reverse-engineering the workflow.

Solution

Formula / code
Power Automate trigger condition for status-driven flows:

@and(
  not(equals(triggerBody()?['Status']?['Value'], triggerBody()?['{VersionNumber}'])),
  equals(triggerBody()?['Status']?['Value'], 'Approved')
)

Safer implementation pattern:
1. Add a PreviousStatus text column to SharePoint.
2. Trigger when item is created or modified.
3. Trigger condition: @not(equals(triggerBody()?['Status']?['Value'], triggerBody()?['PreviousStatus']))
4. Run the flow actions.
5. Update PreviousStatus to the current Status value at the end of the flow.

Implementation checklist

  • Confirm the Power Automate scenario and the business user this pattern supports.
  • Identify the data source, owner, security model, and exception path before building.
  • Build the smallest reusable version first, then add optional branches or polish.
  • Test with realistic data, permissions, edge cases, and handoff expectations.
  • Link this pattern to its collection, topic hub, and related implementation patterns.

Step-by-step instructions

  • Add a PreviousStatus tracking column when SharePoint version comparison is not enough.
  • Configure the trigger condition so the flow only runs when Status differs from PreviousStatus.
  • Run the approval, notification, or update logic only after the trigger condition passes.
  • Update PreviousStatus at the end of the flow to prevent duplicate runs.

When to use

  • Status-driven workflows
  • Approval starts
  • Submission notifications

When not to use

  • Flows that intentionally audit every item change

Common mistakes

  • Putting the condition after the trigger, which still consumes a run.
  • Using the display label incorrectly for choice fields.

Troubleshooting

  • If the flow never starts, inspect the trigger payload and confirm the choice value path.

FAQ

When should I use Power Automate Run a flow only when status changes?

Use Power Automate Run a flow only when status changes when the same Power Automate scenario is likely to appear in more than one app, flow, list, table, or environment and needs a repeatable implementation approach.

Does this pattern work with Power Automate, SharePoint?

Yes. This pattern is written for Power Automate, SharePoint scenarios, but you should still confirm connectors, licensing, permissions, delegation limits, and environment rules before using it in production.

What usually causes this Power Automate pattern to fail?

The most common failure points are unclear ownership, missing validation, weak exception handling, undocumented permissions, and testing only the happy path.

Is Power Automate Run a flow only when status changes beginner friendly?

This pattern is rated Intermediate. Beginners can use the fit guidance and checklist first, while experienced builders can move directly into the formula, flow, schema, or governance details.

Related patterns