How to Use Power Automate Scopes and Configure Run After to Build Reliable Error-Handling Flows

Introduction

As Power Automate flows become more complex, managing errors and troubleshooting failed actions can become challenging.

One of the best ways to organize complex flows is by using Scopes together with Configure Run After.

Scopes allow you to group related actions into a single logical block, while Configure Run After allows you to control when another action or scope should execute based on the previous step's result.

What Is a Scope in Power Automate?

A Scope is a container that allows you to group multiple actions together.

For example, instead of having all actions directly inside a flow:

Get SharePoint Item
Update SharePoint Item
Send Email
Create Log

You can organize them like this:

Scope – TRY
    ↓
Get SharePoint Item
    ↓
Update SharePoint Item
    ↓
Send Email

Scope – CATCH
    ↓
Send Error Notification
    ↓
Create Error Log

This makes the flow easier to understand and maintain.

Example: SharePoint Approval Flow

Imagine you have a flow that processes an invoice approval.

The flow needs to:

1. Get invoice details.

2. Update the invoice status.

3. Update GL coding details.

4. Send an approval notification.

5. Log the result.

Instead of creating a flat flow, use separate scopes.

🟢 Scope 1 – TRY

Scope – TRY
│
├── Get Invoice Item
│
├── Get GL Coding Details
│
├── Update Invoice Status
│
├── Update GL Coding Details
│
└── Send Approval Email

All the main business logic is contained inside the TRY scope.

🔴 Scope 2 – CATCH

Create another scope after the TRY scope.

Scope – CATCH
│
├── Get Error Information
│
├── Create Error Log
│
└── Send Error Notification

The important part is configuring the Run After settings.

Configure Run After

Select the CATCH scope and open:

⋯ → Configure run after

You can configure it to run when the TRY scope:

• ✅ Is successful

• ❌ Has failed

• ⏱️ Has timed out

• ⏭️ Is skipped
  

For an error-handling scope, typically select:

☐ is successful
☑ has failed
☑ has timed out
☐ is skipped

Now the CATCH scope will execute when the TRY scope fails or times out.

Flow Structure

A production-style flow could look like this:

Trigger
   ↓
Validate Request
   ↓
┌──────────────────────────────┐
│       SCOPE – TRY            │
│                              │
│ Get SharePoint Item          │
│        ↓                     │
│ Update Invoice               │
│        ↓                     │
│ Update GL Coding             │
│        ↓                     │
│ Send Email                   │
└──────────────────────────────┘
              ↓
       Configure Run After
       Failed / Timed Out
              ↓
┌──────────────────────────────┐
│      SCOPE – CATCH           │
│                              │
│ Create Error Log             │
│        ↓                     │
│ Send Error Notification      │
└──────────────────────────────┘
              ↓
┌──────────────────────────────┐
│      SCOPE – FINALLY         │
│                              │
│ Update Execution Status      │
│ Log Completion                │
└──────────────────────────────┘

This pattern is commonly called the Try–Catch–Finally pattern.

Why Use TRY, CATCH and FINALLY?

1. TRY – Business Logic

The TRY scope contains the actual business process.

For example:

Get Invoice
↓
Validate Invoice
↓
Update Invoice
↓
Update GL Coding
↓
Send Notification

If everything succeeds, the flow continues normally.

2. CATCH – Error Handling

The CATCH scope handles exceptions.

For example:

TRY failed
     ↓
CATCH
     ↓
Create Error Log
     ↓
Send Teams/Email Notification

Instead of allowing the flow failure to go unnoticed, you can record exactly what happened.

3. FINALLY – Cleanup / Completion

A FINALLY scope can be used for actions that should happen regardless of whether the TRY scope succeeds or fails.

For example:

FINALLY
↓
Update Execution Status
↓
Set End Time
↓
Store Processing Result

Configure Run After for the FINALLY scope to run after the TRY/CATCH processing as appropriate.

Example: Error Logging

Suppose the Update Invoice action fails.

Without proper error handling, you may only see:

ActionFailed

With a structured error-handling design, you can create an error log containing information such as: