Decide what a successful result looks like
Imagine a weekly client-delivery report: read a work list, prepare the summary and save one report file for the agreed reporting period. A green run is useful only if the correct report exists. In this made-up example, success means the expected period's file exists, opens and contains the agreed records.
Write down the report period, where the file belongs, what it should contain and who checks failures. Use an approved development folder and invented records while building. Keep test notifications in Compose actions until you agree where to send them and who should receive them.
Separate the work from the failure path
Microsoft documents scopes and Run after settings for handling failed or timed-out work. Build the following small pattern in a development flow. Keep the failure path separate from the normal success path. See Power Automate error handling.
- Try scopeRead the approved source, prepare the summary and write the report.
- Success branch after TryRun only when Try succeeds. Record the output location after checking it is usable.
- Catch scope after TryRun only when Try has failed or timed out. Record what went wrong and what the owner should do next.
In Catch, start with a Compose action named Failure note. Use a made-up report period and a short problem description while testing. To get the run ID, add a separate Compose using this expression:
workflow()?['run']?['name']The workflow() object gives you details about the flow run, not the report period. Keep both so the owner can connect each attempt to the affected report.
Keep a business failure visible. Inside Catch, add Terminate with status Failed. Configure it after the diagnostic/notification step for all four outcomes: succeeded, failed, skipped and timed out. Keep it inside Catch, so it does not fire when Try succeeds and Catch is skipped. Inspect the run history to confirm this behavior in your flow.
Retry temporary problems, then check the result
A brief service outage may be fixed by trying again. A missing required value or permission needs a different fix. Limit the number of retries and use them only when repeating the action is safe. Microsoft explains temporary failures, longer waits between retries and checks for actions that are safe to repeat. See Power Platform transient-fault guidance.
For the report example, decide what “already produced” means. A stable key such as DeliverySummary-2026-09-25 can identify the intended period. If you are unsure whether the file was saved, look for that key in the destination and check the contents before running the flow again. Agree whether a retry should replace the report or create a new version.
A key alone does not prevent duplicates. The action that saves the result must follow the agreed rule even when runs overlap. If an email was sent before a later action failed, rerunning the whole flow can send it again. Check the run and what it produced before repeating an action that changes data or sends a message.
Leave a short note that helps someone fix it
Give the person fixing the flow these five details:
- Period or item key: which report or result is affected.
- Run ID: which attempt the owner should check.
- Failed stage: read, prepare, save or notify.
- Observed result: missing, partially written, already present or unknown.
- Next action: inspect the destination, correct an input or restore an approved connection.
Do not copy whole source records or confidential request bodies into email. Use an approved destination with appropriate access. An alert sent through the same broken connection can fail too. Include a run-history check in the instructions; trying to send an alert does not prove it arrived.
For a connection error, inspect the connection's status and follow Microsoft's connection troubleshooting guidance. Trying again will not fix missing access.
Test what happens when the flow fails
| Test | What to check |
|---|---|
| Normal sample report | Try succeeds; Catch is skipped; the period's output is correct. |
| Deliberate failed action in Try | Catch runs; the failure note identifies the period; the run ends Failed. |
| Timed-out work, where a limited test is supported | Check that Catch handles the timeout. If you did not test it, say so. |
| Diagnostic or test notification step fails | The Terminate action inside Catch still ends the run Failed. |
| Output exists before running the flow again | The retry replaces it or creates a new version, following the agreed rule. |
To test the failure steps without contacting an external service, add a temporary Compose inside Try with the expression int('not-a-number') in the development copy. It is intentionally invalid at runtime. Remove it after the check. Never introduce this test action into a live reporting flow.
These are tests for you to run, not results we have observed. Before release, note any timeout or duplicate checks you have not tested. For help agreeing how the flow should work and recover from failures, use a workflow review. For the report definition itself, start with the weekly reporting guide and template.
Technical sources checked September 25, 2026. The scopes and made-up report are teaching examples. We have not exported this flow or tested it in a Microsoft environment.