Create a flow run logging list

What this pattern solves

Search intent

Help a Power Platform builder understand when to use Power Automate Create a flow run logging list, how to implement it, and what mistakes to avoid before using it in a production business app.

Problem

Teams often rebuild this flow documentation solution from scratch, which creates inconsistent behavior and avoidable support issues.

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 Create a flow run logging list:
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 Flow documentation 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 Create a flow run logging list 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 building flow documentation capabilities in Power Automate.
• Use when the team needs a repeatable implementation pattern instead of one-off notes.
• Use when supportability, clear ownership, and business-readable behavior matter.

When not to use

• Avoid when the process is still too undefined to standardize.
• Avoid when tenant policy, compliance, or licensing requires a different approved architecture.

Common mistakes

• Building the pattern before naming the owner and lifecycle.
• Using display labels where stable IDs, internal names, or structured fields are needed.
• Skipping error, empty-state, or exception handling until after launch.

Troubleshooting

• If results look inconsistent, inspect the source data shape and compare it to the fields used by the pattern.
• If users are confused, simplify the status labels, ownership fields, or action text before adding more automation.

FAQ