Route approvals by change impact

What this pattern solves

Search intent

Help a Power Platform builder understand when to use Power Automate Route approvals by change impact, how to implement it, and what mistakes to avoid before using it in a production business app.

Problem

Teams often need route approvals by change impact but lose time recreating the same structure without clear ownership, validation, or support notes.

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

Power Automate implementation for Route approvals by change impact:
1. Trigger: When an item is created or modified, When a row is added, or Power Apps (V2).
2. Trigger condition: @not(equals(triggerBody()?['Status']?['Value'], 'Draft'))
3. Try scope:
   - Get source record
   - Validate required fields
   - Execute Approval workflows actions
   - Update Status, LastProcessedOn, LastProcessedBy, and FlowRunUrl
4. Catch scope configured after Try has failed, timed out, or skipped:
   - Update ProcessingStatus = Failed
   - Store ErrorMessage = outputs('Compose_Error_Message')
   - Notify the support owner
5. Finally scope:
   - Append an audit row with SourceItemId, Outcome, RunId, and Timestamp

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

• Create or update the trigger for Route approvals by change impact and add a trigger condition where possible.
• Initialize tracking values such as SourceItemId, RunStatus, OwnerEmail, and ErrorMessage.
• Place core actions in a Try scope, failure handling in a Catch scope, and logging in a Finally scope.
• Run one happy-path test and one failure-path test, then confirm the source record is updated correctly.

When to use

• Use when route approvals by change impact is part of a repeatable business process.
• Use when the team needs a clear starter pattern that can be adapted safely.
• Use when maintainability and business-readable documentation matter.

When not to use

• Avoid when the business process has not been agreed with owners.
• Avoid when an enterprise platform already governs this workflow with stricter controls.

Common mistakes

• Skipping the ownership model before building the pattern.
• Using unstructured text where reporting needs structured fields.
• Launching without testing the exception path.

Troubleshooting

• If the pattern is hard to report on, convert key values into choice, date, person, or lookup fields.
• If users do not follow the process, simplify the labels and make the next action more explicit.

FAQ