10.4 Error Handling, Configure Run After & Scope Controls
Key Takeaways
- By default, Power Automate actions execute only when the immediately preceding action 'is successful' (Succeeded); if an action fails, subsequent actions are skipped and the flow fails.
- 'Configure Run After' settings allow actions to run based on four execution states: is successful, has failed, is skipped, and has timed out.
- The enterprise Try-Catch-Finally pattern groups critical logic into a 'Try' Scope, error logging and alerts into a 'Catch' Scope (run after Try has failed/timed out/is skipped), and cleanup actions into a 'Finally' Scope (run after Catch regardless of result).
- The Terminate action halts flow execution with a status of Succeeded, Cancelled, or Failed; specifying a custom Error Code and Message inside a Catch block ensures failed runs are accurately reported in telemetry.
- Action retry policies can be customized between Default (exponential backoff), Fixed interval, Exponential interval, and None (essential for non-idempotent transactional actions).
Error Handling, Configure Run After & Scope Controls
In mission-critical enterprise environments, automated cloud flows must be resilient to external system outages, network timeouts, invalid payloads, and transient API rate limits. Without explicit error handling, a single action failure causes all downstream actions to be skipped, leaving transactions half-completed, records orphaned in locked states, and support teams unaware of system disruptions.
For the PL-200: Microsoft Power Platform Functional Consultant exam, you must master the mechanics of Configure Run After, implement the industry-standard Scope-based Try-Catch-Finally pattern, configure action Retry Policies and Timeouts, and utilize the Terminate action to ensure accurate operational telemetry.
1. Flow Execution State Machine & Status Codes
Every action executed by the Power Automate workflow runtime concludes in one of four discrete execution states:
+-----------------------------------------------------------------------------+
| ACTION EXECUTION STATUS STATES |
| |
| [SUCCEEDED] ---> Action completed successfully with HTTP 2xx or valid ops|
| |
| [FAILED] ---> Action threw an unhandled error, HTTP 4xx/5xx, or crash |
| |
| [SKIPPED] ---> Action was bypassed because predecessor failed/skipped |
| |
| [TIMED OUT] ---> Action exceeded configured timeout or gateway limit |
+-----------------------------------------------------------------------------+
The Default Flow Execution Behavior
By default, every action is configured to run only if the preceding action is successful (Succeeded).
- If Action 1 succeeds, Action 2 executes.
- If Action 2 fails, the engine immediately halts the sequential pipeline: Action 3 and Action 4 are marked as
Skipped, and the overall flow run status is recorded asFailed.
2. Configure Run After Mechanics
The Configure Run After setting allows makers to alter the default execution dependency of any action. By accessing an action's ellipsis menu (...) > Configure run after, you can select which status outcomes of the preceding action will trigger the current action.
+-----------------------------------------------------------------------------+
| CONFIGURE RUN AFTER SELECTION GRID |
| |
| Run 'Notify_DevOps_On_Failure' after 'Execute_Payment_Gateway' : |
| |
| [ ] is successful (Predecessor returned Succeeded) |
| [X] has failed (Predecessor threw error / HTTP 4xx/5xx) |
| [X] is skipped (Predecessor was bypassed due to upstream fault) |
| [X] has timed out (Predecessor exceeded max duration limit) |
+-----------------------------------------------------------------------------+
The Four Run After Conditions
is successful: Executes when the predecessor action finishes with statusSucceeded. (Default setting).has failed: Executes when the predecessor action encounters any operational failure (e.g., Dataverse record not found, REST API 500 error, division by zero).is skipped: Executes when the predecessor action was not executed because an upstream step failed or a conditional branch was not taken.has timed out: Executes when the predecessor action exceeds its maximum execution duration (e.g., an HTTP webhook listener that received no response within its timeout window).
3. The Scope Control & Try-Catch-Finally Pattern
Configuring run-after settings on individual individual actions across a 30-step flow is unmaintainable. The enterprise best practice is the Scope-based Try-Catch-Finally pattern.
A Scope is an organizational container that groups multiple actions. The Scope itself reports a collective status: if all actions inside the Scope succeed, the Scope status is Succeeded; if any action inside the Scope fails, the Scope status immediately becomes Failed.
+-----------------------------------------------------------------------------+
| ENTERPRISE TRY-CATCH-FINALLY ARCHITECTURE |
| |
| +---------------------------------------------------------------------+ |
| | SCOPE: Scope - Try | |
| | - Action 1: Query ERP System (HTTP GET) | |
| | - Action 2: Transform Data with Data Operations | |
| | - Action 3: Update Dataverse Master Record | |
| +---------------------------------------------------------------------+ |
| | |
| Configure Run After: has failed / is skipped / timed out |
| v |
| +---------------------------------------------------------------------+ |
| | SCOPE: Scope - Catch | |
| | - Action 1: Send High-Priority Teams / Email Alert to DevOps | |
| | - Action 2: Create Incident Row in Dataverse Issue Table | |
| | - Action 3: Terminate (Status: Failed, Code: 'ERP-500', Message: ..)| |
| +---------------------------------------------------------------------+ |
| | |
| Configure Run After: is successful / has failed / |
| is skipped / has timed out |
| v |
| +---------------------------------------------------------------------+ |
| | SCOPE: Scope - Finally | |
| | - Action 1: Unlock Dataverse Record (Clear Processing Lock Flag) | |
| | - Action 2: Write Execution Audit Log Record | |
| +---------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------+
Implementing the Pattern Step-by-Step
- Create
Scope - Try: Place all core business logic actions inside this scope. Leave its run-after settings as default (is successful). - Create
Scope - Catch: Place error notification, logging, and rollback actions inside this scope. Open its Configure run after settings and checkhas failed,is skipped, andhas timed out(uncheckingis successful). - Create
Scope - Finally: Place cleanup actions (unlocking resources, logging audit entries) inside this scope. Open its Configure run after settings and check all four boxes:is successful,has failed,is skipped, andhas timed out. This guaranteesScope - Finallyexecutes under every possible scenario.
Extracting Detailed Error Payloads: result()
To extract the exact error message and failing step name from Scope - Try, use the result('Scope_Try') WDL expression. This returns an array containing the execution output of every action inside the Try scope. You can pass this array into a Filter array action where item()?['status'] is equal to 'Failed' to isolate the exact error details.
4. The Terminate Action & Run History Accuracy
The Terminate action immediately halts the entire flow execution run. It is critical for managing the overall flow run status displayed in Power Automate run history and administrative analytics.
+-----------------------------------------------------------------------------+
| TERMINATE ACTION STATUS MODES |
| |
| [SUCCEEDED] ---> Halts flow immediately; marks overall run as Succeeded |
| (Used for early-exit business logic where no work needed|
| |
| [CANCELLED] ---> Halts flow immediately; marks overall run as Cancelled |
| (Used when process is aborted due to external state) |
| |
| [FAILED] ---> Halts flow immediately; marks overall run as Failed |
| Exposes mandatory: 'Code' (e.g., ERR-402) and |
| 'Message' (e.g., 'Payment processor declined card') |
+-----------------------------------------------------------------------------+
[!CAUTION] The 'Catch Scope False Positive' Trap on PL-200: When an error occurs in
Scope - Try, execution routes intoScope - Catch. If the actions insideScope - Catch(such as sending an email) execute successfully, Power Automate considers the final step of the flowSucceeded. As a result, the overall flow run will be marked as 'Succeeded' in run history, masking the underlying failure from administrators! To prevent this false positive, always place aTerminateaction configured with Status =Failedas the final step of the Catch block or after Finally.
5. Action Retry Policies & Timeout Configuration
In addition to flow-level branching, individual actions provide settings to handle transient network faults and enforce duration limits.
+-----------------------------------------------------------------------------+
| ACTION RETRY POLICY SETTINGS |
| |
| [DEFAULT (EXPONENTIAL)] ---> 4 retries with exponential backoff delays |
| [FIXED INTERVAL] ---> Specific retry count at fixed delay (e.g. 5s|
| [EXPONENTIAL INTERVAL] ---> Specific retry count with min/max intervals|
| [NONE] ---> Zero retries; fails immediately on error |
| (MANDATORY for non-idempotent payments) |
+-----------------------------------------------------------------------------+
Retry Policy Configurations
In any action's Settings > Retry Policy, makers can choose:
- Default: Automatically performs 4 retries using an exponential backoff algorithm.
- None: Disables retries entirely. Fails immediately upon the first error. Critical rule: Use
Nonefor non-idempotent operations (such as credit card charges or non-reversible ERP postings) to prevent accidental duplicate transactions. - Fixed Interval: Retries a specified number of times (e.g., 3) with a static delay between attempts (e.g.,
PT10S). - Exponential Interval: Retries a specified number of times with randomized exponential backoff between a configured minimum and maximum duration.
Action Timeout Configuration
By default, asynchronous cloud flow actions wait up to 30 days (P30D) for a callback or completion. In an action's Settings > Timeout, makers can define an ISO 8601 duration string (e.g., PT2M for 2 minutes, PT30S for 30 seconds). If the action does not complete within this window, it terminates with status TimedOut, allowing downstream Configure Run After branches to catch the timeout.
A functional consultant implements a cloud flow containing a 'Scope - Try' and a 'Scope - Catch'. When an HTTP action inside 'Scope - Try' fails, the flow successfully branches into 'Scope - Catch', sends an email alert to the system administrator, and finishes. However, the IT support team reports that the Power Automate run history dashboard displays the flow run status as 'Succeeded', making it impossible to detect failures through automated monitoring alerts. What should the consultant do to ensure the flow run is accurately recorded as Failed?
A consultant needs to configure a 'Scope - Finally' container in a flow to guarantee that a Dataverse record lock is cleared and an audit entry is created, regardless of whether the preceding business logic in 'Scope - Try' succeeded, failed, timed out, or had actions skipped. How should the 'Configure run after' settings of 'Scope - Finally' be configured?
An automated cloud flow invokes a third-party payment gateway connector action to charge a customer's credit card. If the gateway encounters a network glitch during processing, the consultant must ensure the flow does NOT automatically retry the charge, as duplicate retries could result in multiple charges to the customer account. How should the action settings be configured?
A functional consultant needs to extract the specific error message and name of the failed action from inside 'Scope - Try' to include in an automated DevOps alert. Which expression function provides access to the array of child action statuses and outputs from a Scope?