When Your Power Automate Flow Becomes Too Deep: Understanding the Eight-Level Nesting Limit

A practical guide to recognising the limit, recovering safely, and designing flows that remain supportable as they grow.

Power Automate makes complex automation feel deceptively simple. We add a condition, place a loop inside it, add another condition, and continue building. Every individual step looks reasonable. The flow saves, runs and grows with the requirement.

Then one day we add a small improvement, perhaps an email validation check or a Try/Catch Scope and Power Automate refuses to save it.

The error usually looks similar to this:

The template action is nested at level 9, which exceeds the maximum nesting limit of 8.

This can be confusing because the new action may be completely valid. The problem is not necessarily the expression, connector or action configuration. The problem is the depth of the flow.

I encountered this while improving the reliability of an already complex flow. The change itself was sensible: validate data before sending an email and isolate failures so that one bad record would not stop every other record. However, placing one more container around the existing processing pushed the deepest action from level eight to level nine.

That experience reinforced an important lesson: in Power Automate, good logic still needs a structure that fits the platform.

What does “nesting” mean?

Nesting happens whenever an action is placed inside a container. Common containers include:

• Conditions
• Apply to each loops
• Do until loops
• Switch cases
• Scopes

Imagine a set of boxes. An action at the top of the flow is sitting on the table. Put it inside a Condition and it is now inside one box. Put that Condition inside a loop and it is inside two boxes. Add more loops, branches and Scopes, and the action moves deeper with every layer.

For example:

Condition                         Level 1
└── Apply to each                 Level 2
    └── Apply to each             Level 3
        └── Condition             Level 4
            └── Apply to each     Level 5
                └── Scope         Level 6
                    └── Action    Deeply nested action

The designer may still look manageable because containers can be collapsed. Power Automate, however, validates the complete hierarchy when the flow is saved. If the deepest action exceeds the supported limit, the whole definition is rejected.

Why this often appears during a “small” change

The nesting problem normally remains invisible until the flow is already close to the limit. A developer can add dozens of actions at the same level without increasing depth. One new Condition or Scope, however, adds a layer to every action placed inside it.

Consider a flow that already groups records like this:

Owner
└── Project
    └── Category
        └── Stage
            └── Individual record

Now imagine wrapping that structure in:

Scope - Try
└── Condition - Data is valid
    └── Existing grouping logic

The change adds only two visible containers, but every deeply nested action is now two levels deeper. Actions such as Increment variable or Append to string variable are often the first ones named in the save error because they sit at the bottom of the hierarchy. They are not faulty; they are simply too deep.

The wrong way to recover

When the flow refuses to save, it is tempting to start deleting actions quickly. That is dangerous, especially in the classic designer, because deleting a Scope or Condition also deletes everything inside it.

A safer recovery process is:

1. Do not refresh or close the designer immediately. The browser may still hold the unsaved version.
2. Identify the container that introduced the additional level.
3. Move its child actions out before deleting the container.
4. Restore the previous hierarchy.
5. Save and confirm that the original flow is valid again.
6. Redesign the improvement using a flatter pattern.

If the designer offers recovery of a locally stored copy, treat it carefully. First confirm whether it represents the last good version or the invalid unsaved version.

Pattern 1: Validate earlier, not deeper

Suppose the flow should send emails only to users who have an email address. A natural design is:

Apply to each user
└── Condition: Email is present
    └── All existing processing

This is logically correct, but it adds another level around the entire processing branch.

A flatter alternative is to filter invalid records at the data-retrieval stage. For Dataverse, this could mean using FetchXML or an OData filter to return only records whose related user has a non-null email address. The loop then receives only eligible records.

This approach has three benefits:

• It avoids another nested Condition.
• It reduces the number of records processed by the flow.
• It makes the eligibility rule explicit at the data boundary.

This is a broader design principle: filter as close to the source as possible.

There is one caution. A not-null filter confirms that a value exists; it does not guarantee that the address is perfectly formatted or deliverable. Connector failures still need to be handled.

Pattern 2: Place failure handling beside the work

The familiar Try/Catch pattern in Power Automate uses two Scopes:

Scope - Try
Scope - Catch   (runs after Try fails or times out)

This is a good general pattern, but wrapping an already deep flow in a Try Scope can exceed the nesting limit.

When that happens, place a failure handler after a meaningful top-level action or container instead of wrapping the entire implementation. Configure it with Run after for:

• Has failed
• Has timed out
• Is skipped, when a skipped action indicates an earlier failure

For example:

Main processing condition
↓ failure, timeout or unexpected skip
Scope - Handle Flow Failure

The failure Scope is a sibling, not a parent. It adds supportability without pushing the existing inner loops one level deeper.

This pattern should include useful operational information such as:

• Flow name
• Run identifier
• Failure time
• A link or instruction for finding the failed run
• A notification to the support team
• A failure log record, if a logging table exists

Pattern 3: Add actions at a shallow level

Not every new action increases nesting. An action added after an existing loop, at the same level as that loop, does not make the actions inside the loop any deeper.

For example, a consolidated email may be built through several nested grouping loops, while the final Send email action sits directly inside the outer owner loop. A delivery-log action can safely sit immediately after Send email:

Apply to each owner
├── Nested processing that builds the message
├── Send email
├── Create delivery log
└── Continue after logging

The delivery log should run only after Send email succeeds. A small continuation action can then be configured to run whether logging succeeds, fails, times out or is skipped. This prevents a non-critical logging problem from stopping later owners.

Be deliberate here: handling a failure keeps the automation moving, but it can also make the overall run appear successful. The failed action will remain visible in run history, so monitoring and alerting are still important.

Pattern 4: Move reusable work into a child flow

If the flow repeatedly reaches the nesting limit, small adjustments will only postpone the problem. A child flow is often the cleanest long-term solution.

Good candidates for extraction include:

• Building one recipient’s email body
• Processing one grouped set of records
• Writing notification history
• Formatting a complex HTML section
• Handling a single business transaction

The parent flow becomes an orchestrator:

Retrieve eligible records
↓
Identify recipients
↓
Call child flow for each recipient
↓
Record the outcome

The child flow owns the detailed processing and returns a clear result such as Succeeded, Failed or Skipped. This reduces nesting in the parent and makes the extracted logic easier to test independently.

The trade-off is operational complexity. Child flows require solution-aware design, connection references, well-defined inputs and outputs, and appropriate error propagation. They are most valuable when the extracted responsibility is stable and reusable — not merely as a way to hide an untidy section.

Pattern 5: Replace procedural loops with data operations

Deep flows often use several nested loops to group records and build output. Sometimes this is unavoidable, but sometimes Data Operations can flatten the design:

• Filter array can select matching records.
• Select can reshape data.
• Union can help produce distinct values.
• Join can combine prepared text fragments.
• FetchXML can perform filtering, joining and ordering before records reach the flow.

For example, an inner Apply to each that only converts records into HTML fragments may be replaceable with Select followed by Join. Removing even one inner loop can create enough structural space for validation or error handling elsewhere.

This refactoring needs careful testing. Variables, ordering and formatted output can behave differently when procedural loops are replaced with array operations.

Retry policies need judgement

Supportability reviews often recommend adding retries everywhere. That advice is too broad.

Retries are usually appropriate for transient failures in read-only operations, such as retrieving configuration or listing records. An exponential retry policy can help with short-lived throttling or service interruptions.

Sending an email is different. If the mail service accepts a request but the connector times out before returning a success response, an automatic retry can send the same email twice. A notification log and deduplication key reduce the risk of a complete rerun, but they cannot provide a perfect exactly-once guarantee for an external email operation.

For side-effecting actions, decide explicitly:

• Is a duplicate worse than a delayed message?
• Can the operation use an idempotency key?
• Is there a reliable Sent record?
• Should Failed or Pending records be retried automatically or reviewed?

Retries are a business decision as much as a technical setting.

A practical design checklist

Before extending a complex flow, I now check the following:

1. What is the deepest action in the current design?
2. Will the proposed Condition, Scope or loop wrap existing containers?
3. Can invalid data be filtered at the source?
4. Can the new action be placed after a loop instead of around it?
5. Can one inner loop be replaced with Select, Filter array or Join?
6. Would a child flow create a cleaner responsibility boundary?
7. Does failure handling preserve visibility as well as continuity?
8. Could a retry create a duplicate side effect?
9. Have I tested successful, failed, skipped and timed-out paths?
10. Can another developer understand the structure without expanding every container?

Final thought

The eight-level nesting limit is frustrating when it first appears, but it is also a useful architectural signal. It usually means the flow has accumulated too many responsibilities or that procedural logic has become too deeply layered.

The answer is not to abandon Conditions, loops or Scopes. They remain essential Power Automate building blocks. The answer is to use them with awareness: filter earlier, keep orchestration shallow, place handlers beside deep work, extract clear responsibilities and treat retries carefully.

A flow should not only work today. It should leave enough structural space for tomorrow’s validation rule, operational log or failure-handling requirement. That is what turns a working automation into a supportable one.