Validate a conditional approval flow

What this pattern solves

Search intent

Help a Power Platform builder understand when to use Power Automate Validate a conditional approval flow, how to implement it, and what mistakes to avoid before using it in a production business app.

Problem

Teams often need to validate a conditional approval flow but lose time recreating the structure, fields, decisions, and support notes from scratch.

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 Validate a conditional approval flow:
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 Power Automate delivery patterns 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 Validate a conditional approval flow 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 the organization needs to validate a conditional approval flow as part of a repeatable process.
• Use when the solution should be understandable by both builders and business owners.
• Use when consistency, supportability, and governance matter more than a one-off workaround.

When not to use

• Avoid when the workflow is temporary and does not need reusable structure.
• Avoid when an existing enterprise system already governs the process end to end.

Common mistakes

• Starting with automation before the business rule is agreed.
• Using unstructured notes where structured fields are needed for reporting.
• Skipping the exception path until users find it in production.

Troubleshooting

• If reporting is weak, identify which values need to become structured fields.
• If adoption is weak, simplify the next action and remove unnecessary choices.

FAQ