Power Automate approval workflows: multiple stages, delegation, and escalation

How is a Power Automate approval workflow built to reliably handle multiple approval stages, delegations, and overdue decisions? The stable approach separates the business request, the individual approval stages, and each specific decision. Power Automate controls the flow and sends approval requests; the persistent process status must also be stored in a SharePoint list, Dataverse table, or another system of record. Only then can the status still be analyzed if an approval expires, a flow fails, or the person responsible changes.

A multi-stage workflow is therefore not a single Start and wait for an approval block. It is a state model with clear transitions, deadlines, idempotency, error handling, and a controlled fallback path. If approvals generate tasks or write status values to SharePoint, the patterns from Connect SharePoint tasks with Power Automate and Write to SharePoint lists with Power Automate are directly applicable.

When a Power Automate approval workflow is necessary

A formal approval is sensible when a decision must be demonstrably assigned to a person or role, and the subsequent process depends on that decision. Examples include procurements, contract reviews, publications, investments, or exceptions to policies.

Not every consensus process requires an approval. For informal inquiries, collaborative work, or pure information sharing, Teams comments, tasks, or status fields may be more suitable. An unnecessarily formal workflow increases cycle time and notification volume.

Four basic variants

Variant: Single approval

Behavior: one person decides

Suitable for: clear owner

Main risk: absence blocks progress

Variant: First to respond

Behavior: one response is sufficient

Suitable for: equivalent on-call pool

Main risk: the fastest person decides unintentionally

Variant: Everyone must approve

Behavior: all must agree

Suitable for: shared responsibility

Main risk: a missing participant blocks progress

Variant: Custom answers

Behavior: defined options instead of Yes/No

Suitable for: return, request for additional information, conditional approval

Main risk: more complex evaluation

Multi-stage means that after one decision, another stage follows. Parallel means that multiple approval branches run simultaneously. Both patterns can be combined.

Define the business data model before the flow

List or table Anträge

The application contains the business data and the overall status:

• Application ID,
• Application type,
• Applicant,
• Cost center or organizational unit,
• Amount or risk class,
• submitted on,
• current stage,
• overall status,
• current responsibility role,
• final decision,
• completed on,
• last technical processing,
• correlation ID.

A correlation ID links Flow executions, approval records, logs, and notifications. It should be generated upon first submission and not changed with each repetition.

List Genehmigungsstufen

Configuring the stages does not necessarily belong in the flow. A separate table can contain rules:

Field: Process type

Example: Procurement

Field: Stage

Example: 20

Field: Condition

Example: Amount over 10,000

Field: Approver Source

Example: Cost Center Owner

Field: Mode

Example: sequential

Field: Response Type

Example: Approve/Reject/Return

Field: Deadline in Business Days

Example: 3

Field: Escalation Role

Example: Department Head

Field: Absence Rule

Example: central absence list

Configuration improves maintainability but must not be changed uncontrollably by many people. Changes must be versioned, tested, and take effect at a defined point in time.

List Entscheidungen

Each request and response is stored separately:

• Request ID,
• Stage ID,
• Approval ID,
• Intended Approver,
• Responding Person,
• Assignment Time,
• Due Date,
• Response,
• Comment,
• Response time,
• Delegation reason,
• Escalation status,
• technical execution ID.

This preserves the history, even if the overall status is changed later.

Single-stage and multi-stage approvals: structure and data flow

Single-stage process

1. The application is validated and set to Eingereicht.
2. The flow determines the approver from a controlled source.
3. A decision record is created.
4. Approval is started.
5. The response is normalized and stored in the decision record.
6. The application receives Genehmigt, Abgelehnt, or Zurückgegeben.
7. Downstream actions start only based on the stored status.

The last point prevents an email action or an external connector from accidentally being considered the business completion.

Multi-stage process

For multiple stages, the flow should write a stable intermediate state after each decision. Example:

Eingereicht → Fachprüfung offen → Fachlich genehmigt → Budgetprüfung offen → Final genehmigt

This allows a failed execution to be resumed from the last completed stage. Keeping everything in a single long execution makes timeouts, changes, and manual corrections difficult for operations.

Never derive rules solely from display names

Approvers should be determined via stable identities or groups. Display names are not unique. Email addresses can change. For historical proof, a combination of object ID, address stored at the time of assignment, and a readable name is recommended.

Choosing parallel and sequential approvals correctly

Sequential

A sequential approval fits when one decision prepares the next business step or when the next role should only become active after consent. Examples:

• Expert review before budget approval,
• Data privacy review before publication,
• Local approval before central approval.

The advantage is the clear progression. The disadvantage is the longer overall duration.

Parallel

Parallel approvals work when roles can review independently, such as IT security, data privacy, and procurement. In Power Automate, you can use parallel branches or assign an approval to multiple people.

First, the decision rule must be established:

• Must everyone agree?
• Is one agreement sufficient?
• Does one rejection immediately stop all other branches?
• Are already submitted answers still saved?
• What happens with contradictory answers?

Merging after parallel branches

Merging should not only react to the technical status of a branch. Write each partial decision into the decision table and then calculate the overall status. A possible rule is:

• at least one rejection → overall status Abgelehnt,
• all required approvals present → Genehmigt,
• at least one answer pending → In Prüfung,
• technical issue → Klärung erforderlich.

This is more understandable than nested conditions using dynamic flow outputs.

Implement delegation and substitution technically

Resolve substitution before starting

The most robust approach determines before approval creation who is currently responsible. A substitution list can include:

• Primary responsible person,
• Substitute,
• valid from/to,
• process types,
• maximum decision authority,
• approval status of the substitute,
• last review.

The flow checks the date and process type and assigns the approval directly to the valid person. The decision record stores both the original role and the actually addressed person.

Do not confuse reassignment with the substitute concept

Approvals can be reassigned depending on the interface and settings. However, a spontaneous reassignment is not a complete substitute model. It does not automatically answer whether the substitute is authorized in a business sense, whether limits apply, and how the change is logged.

For complex scenarios, Microsoft provides a Business Approvals Kit with extended approval patterns. Its delegation functions are not identical to a simple standard approval and require their own architecture and license review.

Absence as a data source

A calendar absence can be an indicator but is not always a legally secure substitute rule. Appointments can be private, incomplete, or not current. Use calendar data only if the organization has explicitly defined this mechanism. The post Check leave status with SharePoint and Power Automate explains the technical pattern and its limitations.

Build timeouts, reminders, and escalation

Cloud flow runs have documented runtime limits; Microsoft notes that pending steps such as approvals are included in this runtime. Currently, Microsoft documents 30 days for a single cloud flow run; after that, pending steps such as approvals expire. Therefore, an approval process should not hang indefinitely in a waiting action.

Two operating models

Short process: Start and wait for an approval waits within the same execution. This is suitable for manageable deadlines and low complexity.

Long-running process: Approval is created, its ID is stored, and a separate scheduled process monitors open decisions. This decouples business waiting time from a single flow execution and facilitates reminders, escalation, and resumption.

Store deadlines explicitly

Store Fällig am in the decision record. A daily monitoring flow can handle open decisions in stages:

1. friendly reminder before the deadline,
2. reminder on the due date,
3. escalation after exceeding the deadline,
4. technical or business handover after the maximum deadline.

Use a column LetzteErinnerungsstufe so the same notice is not sent again on every run. Time zone, weekends, and holidays must match the process rule. "Three days" is not unambiguous without definition.

Escalation is a process decision

An escalation can inform, reassign, activate an alternative role, or cancel the request. This response cannot be arbitrarily invented by the flow developer. It must be approved by the business team.

Typical failure patterns and fallback paths

Approval appears to hang indefinitely

Causes: incorrect address, deactivated account, missing license or permission, guest user with limited interface, invalid group, or expired flow run.

Test: check the approval ID, recipient, execution status, and notification history; respond using a test account.

Fallback: cancel an open decision under control or mark it as technically failed, correct the recipient, and generate a new decision instance with a reference to the old one.

The same request is started twice

Causes: the trigger reacts to every change, the user clicks multiple times, or a retry generates a new approval.

Protection: use status change as a trigger condition, correlation ID, a unique key derived from the request and stage, and check for already open decisions.

Fallback: mark and close the duplicate approval instance; do not delete the business record.

Rejection path is missing

Symptom: the flow ends technically successfully after a rejection, but the request remains in In Prüfung.

Protection: define an explicit status transition for every possible response.

Fallback: use a correction flow or controlled manual status correction with an audit comment.

Notification flood

Cause: every change triggers new emails; parallel reviewers receive unnecessary intermediate messages.

Protection: use consolidated notifications, clearly defined events, and stored send stages.

Fallback: disable the reminder flow, export open cases, and restart them specifically after correction.

Flow owner is unavailable

Cause: the flow and connections depend on a single person.

Protection: documented co-owners, appropriate functional identity, solutions, environment variables, and operations handover.

Fallback: replace connections under control, verify permissions, and validate with a test request before allowing open cases to continue.

Test plan for multi-stage approvals

Business paths

• each stage is approved,
• rejection at any possible stage,
• return for correction,
• amount or risk below and above each threshold,
• parallel approval and conflicting responses.

Identities and representation

• primary approver active,
• representation within and outside their validity period,
• disabled account,
• changed email address,
• group with no members,
• external guest, if provided.

Time and escalation

• reminder before due date,
• due date in different time zone,
• weekend or holiday,
• escalation,
• maximum process duration,
• later response after escalation has already occurred.

Technical issues

• SharePoint temporarily unreachable,
• approval action fails,
• notification fails,
• flow is updated while cases are open,
• repeating a failed action,
• manual restart with the same correlation ID.

Acceptance should not only check whether an email arrives. What matters is whether the request, decision, responsible party, deadline, and history remain correct in the leading system.

Operations, monitoring, and changes

A production approval workflow needs at least:

• responsible parties for the business process and technology,
• alerting on failed executions,
• overview of open and overdue decisions,
• versioning of the rules,
• controlled changes in a test environment,
• documented restart procedure,
• regular review of groups, proxies, and connections.

General basic patterns for process automation are described in Optimize processes with Power Automate and SharePoint. A concrete compliance use case can be found in Automatically distribute policies and compliance documents.

How the approval workflow stays stable even with parallel approvals and exceptions

A stable workflow stores not only the final result but also every stage, assignment, deadline, and decision. Sequential and parallel approvals are selected based on business rules, proxies are checked before assignment, and long wait times are decoupled through a monitored state process. With unique keys, explicit fallback paths, and tests for exceptions, the process remains traceable even when people, rules, or technical connections change.