Chapter 5: Power Automate Flow Design

This chapter focuses on the Power Automate side of the integration. You'll learn how to create robust flows that receive webhooks from Business Central, parse JSON data, implement business logic, connect to external services, and handle errors gracefully.

By the end of this chapter, you'll be able to design production-ready Power Automate flows that reliably process Business Central events and integrate with your organization's ecosystem of services.

5.1 Creating Flows in Power Automate

Flow Types

Power Automate offers several flow types:

Automated Cloud Flows

• Triggered by events (our use case)

• HTTP request received from BC

• No user interaction needed

• Run in the background

• This is what we use for BC integration

Instant Cloud Flows

• Triggered manually by user

• Button press in mobile app, SharePoint, Teams

• Not suitable for BC automation

Scheduled Cloud Flows

• Run on a schedule (daily, hourly, etc.)

• Good for batch processing

• Not event-driven

Desktop Flows

• Robotic Process Automation (RPA)

• Automate desktop applications

• Not cloud-based

Business Process Flows

• Guide users through multi-stage processes

• Embedded in model-driven apps

• Not suitable for BC integration

For Business Central Integration, Always Use: Automated Cloud Flow

Creating an Automated Cloud Flow

Step-by-Step Procedure:

Step 1: Access Power Automate

1. Navigate to https://make.powerautomate.com

2. Sign in with your Microsoft 365 or Dynamics 365 credentials

3. Ensure you're in the correct environment (check top-right dropdown)

Step 2: Create New Flow

1. Click "My flows" in left navigation

2. Click "+ New flow" button

3. Select "Automated cloud flow"

Step 3: Name Your Flow

1. Flow name field appears

2. Enter descriptive name:

   • Good: "BC Sales Order Posted - Email Notification"

   • Good: "BC Customer Credit Check"

   • Poor: "Test Flow"

   • Poor: "Flow 1"

3. Clear naming helps when debugging and reviewing run history

Step 4: Skip Trigger Selection

1. Dialog shows available triggers

2. Click "Skip" at bottom

3. We'll add HTTP trigger manually for more control

Step 5: Add HTTP Trigger

1. Click "+ Add a trigger" in canvas

2. Search box appears

3. Type "HTTP"

4. Select "When an HTTP request is received"

5. Trigger appears in canvas

Step 6: Save Flow

1. Click "Save" button (top right)

2. Flow is saved

3. HTTP trigger generates webhook URL

4. Copy webhook URL for use in BC

📋 NOTE: The webhook URL only appears after saving the flow. Save immediately after adding the HTTP trigger, then copy the URL to use in Business Central flow trigger configuration.

Flow Design Principles

Principle 1: Single Responsibility

Each flow should handle one specific business process:

Good Design:

• Flow 1: Sales Order Posted → Email warehouse

• Flow 2: Sales Order Posted → Update CRM

• Flow 3: Customer Created → Add to mailing list

Each flow has a clear, single purpose.

Poor Design:

• Flow 1: Sales Order Posted → Email warehouse, update CRM, add to SharePoint, post to Teams, create task, update external system...

Too complex, hard to debug, single point of failure.

Principle 2: Fail Fast

Validate inputs early in the flow:

Good Pattern:

Poor Pattern:

Principle 3: Idempotency

Design flows to handle duplicate webhooks safely:

Business Central might send the same event twice (rare but possible). Your flow should handle this gracefully:

• Check if action already performed (query target system)

• Use unique identifiers to detect duplicates

• Make actions that can be safely repeated

Example:

Principle 4: Logging and Observability

Build in visibility:

• Use "Compose" actions to format key data for run history

• Add comments to actions explaining purpose

• Use descriptive action names (not "Action 1", "Action 2")

• Log errors to central location (SharePoint list, SQL table)

Principle 5: Error Handling

Every action that can fail should have error handling:

• Use "Configure run after" to define error paths

• Send notifications on failures

• Log errors for investigation

• Provide enough context to diagnose issues

💡 TIP: Start with a simple flow (trigger + one action). Verify it works end-to-end. Then add complexity incrementally, testing after each addition.

Flow Naming and Organization

Naming Convention:

Format: [System] - [Event] - [Action]

Examples:

• BC - Sales Order Posted - Email Warehouse

• BC - Customer Created - CRM Sync

• BC - Inventory Low - Teams Notification

• BC - Invoice Posted - SharePoint Archive

Folder Organization (Environments):

Power Automate allows solutions and environments:

Development Environment:

• All test flows

• Experimental integrations

• Sandbox BC connection

Production Environment:

• Live flows only

• Production BC connection

• Strict change control

Use Solutions:

• Group related flows into solutions

• Example: "BC Sales Integration" solution contains all sales-related flows

• Easier to migrate between environments

• Better organization and governance

Flow Descriptions:

Every flow should have a description:

This provides essential context for maintenance and troubleshooting.

5.2 HTTP Trigger Configuration

Basic HTTP Trigger Setup

The HTTP trigger is already added to your flow. Now configure it properly:

Trigger Properties:

When you click on the HTTP trigger box, it expands to show:

HTTP POST URL

• Generated automatically when flow is saved

• Click copy icon to copy

• Use this URL in BC flow trigger configuration

• Regenerates if you delete and recreate trigger

Who can trigger the flow

• Default: "Anyone" (not recommended for production)

• Options:

  • Anyone: Any HTTP request with correct URL

  • Anyone with an InTune-managed device: Requires device management

  • Specific users in my organization: Requires authentication

For BC integration, typically use "Anyone" since BC authenticates via URL signature, but consider network restrictions for additional security.

Method

• Always POST (fixed for this trigger)

• BC sends HTTP POST requests

Request Body JSON Schema

• Optional but strongly recommended

• Defines expected JSON structure

• Enables dynamic content in subsequent actions

• Provides validation

Generating JSON Schema

The JSON schema helps Power Automate understand your webhook payload structure.

Method 1: Use Sample Payload

Step 1: Get Sample JSON from BC

1. Configure your BC flow trigger with JSON payload

2. Trigger a test event in BC

3. Check BC validation log for the sent JSON

4. Copy the complete JSON payload

Example Sample JSON:

{
  "documentNo": "SO-10001",
  "customerName": "Alpine Ski House",
  "amount": 15450.00,
  "orderDate": "2025-12-09",
  "salespersonCode": "SP001"
}

Step 2: Generate Schema

1. In Power Automate, click the HTTP trigger

2. Scroll to "Request Body JSON Schema" field

3. Click "Use sample payload to generate schema" link

4. Paste your sample JSON

5. Click "Done"

6. Schema appears in field

Generated Schema Example:

{
  "type": "object",
  "properties": {
    "documentNo": {
      "type": "string"
    },
    "customerName": {
      "type": "string"
    },
    "amount": {
      "type": "number"
    },
    "orderDate": {
      "type": "string"
    },
    "salespersonCode": {
      "type": "string"
    }
  }
}

Method 2: Write Schema Manually

If you're comfortable with JSON Schema syntax, write it directly:

{
  "type": "object",
  "properties": {
    "documentNo": {"type": "string"},
    "customerName": {"type": "string"},
    "amount": {"type": "number"},
    "orderDate": {"type": "string", "format": "date"},
    "salespersonCode": {"type": "string"}
  },
  "required": ["documentNo", "customerName", "amount"]
}

The "required" array specifies which fields must be present.

Benefits of Defining Schema:

1. Dynamic Content After defining schema, subsequent actions show available fields in dynamic content picker:

• @{triggerBody()?['documentNo']}

• @{triggerBody()?['customerName']}

• @{triggerBody()?['amount']}

Without schema, you must manually type field references.

2. Validation If BC sends JSON that doesn't match schema, the trigger fails and logs error. This catches configuration mistakes early.

3. IntelliSense Power Automate shows available fields as you type, reducing errors.

4. Documentation Schema documents expected payload structure for future maintainers.

📋 NOTE: Schema is optional but highly recommended. Without it, you can still access webhook data using expressions like triggerBody()['fieldName'], but you lose auto-complete and validation benefits.

Nested JSON Schemas

If your BC payload uses nested objects:

Sample Nested JSON:

{
  "event": {
    "type": "OrderPosted",
    "timestamp": "2025-12-09T10:30:00Z"
  },
  "order": {
    "number": "SO-10001",
    "amount": 15450.00
  },
  "customer": {
    "number": "C-10000",
    "name": "Alpine Ski House"
  }
}

Generated Nested Schema:

{
  "type": "object",
  "properties": {
    "event": {
      "type": "object",
      "properties": {
        "type": {"type": "string"},
        "timestamp": {"type": "string"}
      }
    },
    "order": {
      "type": "object",
      "properties": {
        "number": {"type": "string"},
        "amount": {"type": "number"}
      }
    },
    "customer": {
      "type": "object",
      "properties": {
        "number": {"type": "string"},
        "name": {"type": "string"}
      }
    }
  }
}

Accessing Nested Fields:

• @{triggerBody()?['event']?['type']}

• @{triggerBody()?['order']?['number']}

• @{triggerBody()?['customer']?['name']}

Use ?['fieldName'] syntax for safe access (returns null if field missing rather than error).

Schema Validation Modes

Strict Mode (Recommended for Production):

{
  "type": "object",
  "properties": {...},
  "required": ["documentNo", "amount"],
  "additionalProperties": false
}

"additionalProperties": false means BC cannot send extra fields not in schema. Helps catch errors.

Flexible Mode (Good for Development):

{
  "type": "object",
  "properties": {...},
  "additionalProperties": true
}

Allows extra fields. Good while iterating on payload design.

💡 TIP: Use flexible mode during development. Once payload structure is stable, switch to strict mode to catch accidental changes.

5.3 Parsing Business Central Data

Accessing Webhook Data

After defining JSON schema, access webhook data in actions:

Dynamic Content Picker:

1. Add an action (e.g., "Send an email")

2. Click in a field (e.g., "Subject")

3. Lightning bolt icon appears

4. Click lightning bolt to open dynamic content picker

5. Section labeled "When an HTTP request is received" shows available fields

6. Click field to insert reference

Expression Editor:

For complex expressions, use the expression editor:

1. Click in field

2. Click "fx" button (Expression tab)

3. Write expression using Power Automate expression language

4. Click "OK" to insert

Common Expressions:

Simple Field Access:

triggerBody()?['documentNo']

Nested Field Access:

triggerBody()?['customer']?['name']

Conditional (If-Else):

if(equals(triggerBody()?['amount'], 0), 'No charge', triggerBody()?['amount']

String Concatenation:

concat('Order ', triggerBody()?['documentNo'], ' for ', triggerBody()?['customerName']

Formatting Numbers:

formatNumber(triggerBody()?['amount']

Result: $15,450.00

Formatting Dates:

formatDateTime(triggerBody()?['orderDate']

Result: December 09, 2025

📋 NOTE: The ?['fieldName'] syntax (with question mark) is null-safe. If the field doesn't exist, it returns null rather than causing an error. This is important for optional fields in your payload.

Parse JSON Action

For complex or dynamic JSON structures, use the "Parse JSON" action:

When to Use:

• JSON structure varies between webhooks

• Deeply nested JSON

• Arrays in payload

• Want explicit parsing step for clarity

Step-by-Step:

Step 1: Add Parse JSON Action

1. Click "+ New step" after HTTP trigger

2. Search for "Parse JSON"

3. Select "Parse JSON" (Data Operations)

Step 2: Configure Content

1. Click in "Content" field

2. Select "Body" from dynamic content (from HTTP trigger)

3. This is the raw JSON received from BC

Step 3: Define Schema

1. Click "Generate from sample"

2. Paste sample JSON payload

3. Click "Done"

4. Schema appears

Step 4: Use Parsed Fields

• Subsequent actions show parsed fields in dynamic content

• Access like: @{body('Parse_JSON')?['documentNo']}

Example Flow:

1. When HTTP request received
   (receives webhook)
   
2. Parse JSON
   Content: triggerBody()
   Schema: (generated from sample)
   
3. Compose (for visibility)
   Inputs: Document @{body('Parse_JSON')?['documentNo']} 
           for @{body('Parse_JSON')?['customerName']}
   
4. Send email
   Subject: New Order @{body('Parse_JSON')?['documentNo']

⚠️ WARNING: If you define schema on the HTTP trigger, you typically don't need Parse JSON action—dynamic content is already available. Use Parse JSON when you need additional control or transformation of the received data.

Working with Arrays

If your BC payload includes arrays (rare but possible):

Example Payload with Array:

{
  "orderNo": "SO-10001",
  "lineCount": 3,
  "topItems": ["Item1", "Item2", "Item3"]
}

Accessing Array Elements:

First Element:

first(triggerBody()?['topItems']

Result: "Item1"

Last Element:

last(triggerBody()?['topItems']

Specific Index:

triggerBody()?['topItems'][0]

Result: "Item1" (0-based index)

Array Length:

length(triggerBody()?['topItems']

Result: 3

Iterate Over Array (Apply to Each):

1. Add "Apply to each" action

2. In "Select an output from previous steps", choose the array field

3. Inside the loop, add actions

4. Current item referenced as: item()

Example:

Apply to each: triggerBody()?['topItems']

Sends 3 emails, one per array item.

Data Type Conversions

String to Integer:

int(triggerBody()?['quantityString']

String to Decimal:

float(triggerBody()?['amountString']

Number to String:

string(triggerBody()?['amount']

Date String to DateTime:

formatDateTime(triggerBody()?['orderDate']

Boolean from String:

if(equals(triggerBody()?['isBlocked']

💡 TIP: If BC sends numeric fields without quotes (proper JSON numbers), Power Automate recognizes them as numbers automatically. No conversion needed. Check your BC JSON payload design in Chapter 3.

5.4 Common Flow Patterns

Pattern 1: Email Notification

Use Case: Send email when BC event occurs.

Flow Structure:

1. HTTP Trigger (receive webhook)
2. Send an email (V2)
   To: warehouse@company.com
   Subject: New Order @{triggerBody()?['documentNo']}
   Body: 
     Order: @{triggerBody()?['documentNo']}
     Customer: @{triggerBody()?['customerName']}
     Amount: $@{triggerBody()?['amount']

Key Points:

• Use dynamic content for personalization

• Keep email concise and actionable

• Include link back to BC if possible

• Consider HTML formatting for better readability

HTML Email Body:

<h2>New Sales Order</h2>
<table>
  <tr><td><strong>Order:</strong></td><td>@{triggerBody()?['documentNo']}</td></tr>
  <tr><td><strong>Customer:</strong></td><td>@{triggerBody()?['customerName']}</td></tr>
  <tr><td><strong>Amount:</strong></td><td>$@{triggerBody()?['amount']}</td></tr>
</table>
<p>Please prepare for shipment.</p>

Select "Yes" for "Is HTML" option in email action.

Pattern 2: Conditional Routing

Use Case: Different actions based on webhook data.

Flow Structure:

Condition Configuration:

• Click "+ New step"

• Search "Condition"

• Select "Condition" (Control)

• Choose field: triggerBody()?['amount']

• Select operator: "is greater than"

• Enter value: 10000

• Add actions under "If yes" and "If no" branches

Multiple Conditions:

Use "Add" button to add multiple conditions with AND/OR logic:

Pattern 3: Approval Workflow

Use Case: Require human approval before proceeding.

Flow Structure:

1. HTTP Trigger
2. Start and wait for an approval
   Approval type: Approve/Reject - First to respond
   Title: Approve Order @{triggerBody()?['documentNo']}
   Assigned to: manager@company.com
   Details: 
     Order: @{triggerBody()?['documentNo']}
     Customer: @{triggerBody()?['customerName']}
     Amount: $@{triggerBody()?['amount']}
     
3. Condition: Outcome = Approved?
   
   If Yes:
     4a. Send email: "Order approved"
     5a. Update BC (via API or connector)
     6a. Create shipment task
   
   If No:
     4b. Send email: "Order rejected - reason: @{body('Start_and_wait_for_an_approval')?['response']

Approval Action Configuration:

• Approval type: Choose "Approve/Reject - First to respond" or "Approve/Reject - Everyone must approve"

• Title: Concise description (appears in email subject)

• Assigned to: Email addresses (comma-separated for multiple)

• Details: Complete information for decision-making

• Item link: Optional link back to BC (if you have web client URL)

• Item link description: Text for link

Accessing Approval Outcome:

Outcome: body('Start_and_wait_for_an_approval')?['outcome']
Response: body('Start_and_wait_for_an_approval')?['responses'][0]['comments']
Approver: body('Start_and_wait_for_an_approval')?['responses'][0]['responder']['displayName']

Pattern 4: SharePoint Integration

Use Case: Create or update SharePoint list items with BC data.

Flow Structure:

1. HTTP Trigger
2. Create item (SharePoint)
   Site Address: https://company.sharepoint.com/sites/Sales
   List Name: Sales Orders
   Title: @{triggerBody()?['documentNo']}
   Customer: @{triggerBody()?['customerName']}
   Amount: @{triggerBody()?['amount']}
   Order Date: @{triggerBody()?['orderDate']

Or Update Existing:

1. HTTP Trigger
2. Get items (SharePoint)
   Site Address: https://company.sharepoint.com/sites/Sales
   List Name: Sales Orders
   Filter Query: Title eq '@{triggerBody()?['documentNo']}'
   Top Count: 1
   
3. Condition: Item exists?
   Check: length(outputs('Get_items')?['body']?['value']) greater than 0
   
   If Yes:
     4a. Update item
        Item ID: @{first(outputs('Get_items')?['body']?['value'])?['ID']

💡 TIP: SharePoint list columns must exist before flow can write to them. Create list structure first, then configure flow.

Pattern 5: Teams Notification

Use Case: Post message to Teams channel.

Flow Structure:

1. HTTP Trigger
2. Post message in a chat or channel (Teams)
   Post as: Flow bot
   Post in: Channel
   Team: Sales Team
   Channel: General
   Message: 
     **New Order Posted**
     Order: @{triggerBody()?['documentNo']}
     Customer: @{triggerBody()?['customerName']}
     Amount: $@{triggerBody()?['amount']

Adaptive Card (Richer Format):

Use "Post adaptive card in a chat or channel" for interactive cards:

{
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "type": "AdaptiveCard",
  "version": "1.4",
  "body": [
    {
      "type": "TextBlock",
      "text": "New Order Posted",
      "weight": "Bolder",
      "size": "Large"
    },
    {
      "type": "FactSet",
      "facts": [
        {"title": "Order:", "value": "@{triggerBody()?['documentNo']}"},
        {"title": "Customer:", "value": "@{triggerBody()?['customerName']}"},
        {"title": "Amount:", "value": "$@{triggerBody()?['amount']}"}
      ]
    }
  ],
  "actions": [
    {
      "type": "Action.OpenUrl",
      "title": "View in BC",
      "url": "https://businesscentral.dynamics.com/..."
    }
  ]
}

Paste this JSON into "Message" field of adaptive card action, replacing placeholders.

Pattern 6: HTTP API Call

Use Case: Call external REST API with BC data.

Flow Structure:

1. HTTP Trigger (receive from BC)
2. HTTP (call external API)
   Method: POST
   URI: https://api.external-system.com/orders
   Headers:
     Content-Type: application/json
     Authorization: Bearer YOUR_API_KEY
   Body:
     {
       "externalId": "@{triggerBody()?['documentNo']}",
       "customerName": "@{triggerBody()?['customerName']}",
       "amount": @{triggerBody()?['amount']

Accessing HTTP Response:

Status Code: outputs('HTTP')?['statusCode']
Response Body: body('HTTP')
Specific Field: body('HTTP')?['orderId']

Pattern 7: SQL Database Integration

Use Case: Insert BC data into SQL database.

Flow Structure:

1. HTTP Trigger
2. Insert row (V2) (SQL Server)
   Server name: sql-server.database.windows.net
   Database name: SalesDB
   Table name: BCOrders
   DocumentNo: @{triggerBody()?['documentNo']}
   CustomerName: @{triggerBody()?['customerName']}
   Amount: @{triggerBody()?['amount']}
   PostingDate: @{triggerBody()?['orderDate']

Or Execute Stored Procedure:

2. Execute stored procedure (V2)
   Procedure name: usp_InsertBCOrder
   Parameters:
     @DocumentNo: @{triggerBody()?['documentNo']}
     @CustomerName: @{triggerBody()?['customerName']}
     @Amount: @{triggerBody()?['amount']

Connection Setup:

• First time: Flow prompts for SQL credentials

• Subsequent uses: Reuses connection

• Security: Connection stored securely in Power Automate

Pattern 8: Error Logging

Use Case: Log all webhook receptions for audit/troubleshooting.

Flow Structure:

1. HTTP Trigger
2. Create item (SharePoint - "Integration Logs" list)
   Timestamp: @{utcNow()}
   Source: Business Central
   Event Type: @{triggerBody()?['eventType']}
   Document No: @{triggerBody()?['documentNo']}
   Status: Processing
   Raw Payload: @{string(triggerBody())}
   
3. (Business logic actions here)

4. Update item (on success)
   Status: Success
   Processed At: @{utcNow()}
   
(Error handling - see Section 5.5)
5. Update item (on failure)
   Status: Failed
   Error: @{body('actionName')?['error']?['message']

This creates an audit trail of all integrations.

5.5 Error Handling in Flows

Understanding Flow Failures

Flows can fail at any action:

Common Failure Causes:

• Network connectivity issues

• Target system unavailable (SharePoint, Teams down)

• Authentication expired (connector needs re-auth)

• Invalid data (null values, wrong types)

• Permission issues

• Throttling limits exceeded

Without Error Handling:

• Flow fails and stops

• No notification sent

• Partial work completed (data inconsistency)

• Difficult to diagnose

With Error Handling:

• Flow catches errors gracefully

• Sends notifications

• Logs errors for investigation

• Completes cleanup actions

• Provides context for troubleshooting

Configure Run After

Every action has "Configure run after" settings that control when it executes:

Accessing Configure Run After:

1. Click "..." menu on any action (except trigger)

2. Select "Configure run after"

3. Dialog shows checkboxes:

   • ☑ is successful (default)

   • ☐ has failed

   • ☐ is skipped

   • ☐ has timed out

Default Behavior:

• Action runs only if previous action succeeded

• If previous action fails, subsequent actions skip

Error Handling Behavior:

• Check "has failed" to run action when previous fails

• This creates error handling path

Basic Error Handling Pattern

Flow Structure:

1. HTTP Trigger

2. (Main Business Logic)
   Send email, create record, call API, etc.
   
3. (Success Path - runs if #2 succeeded)
   Configure run after: is successful ☑
   Action: Compose
   Inputs: Success: @{outputs('Action_Name')}
   
4. (Error Path - runs if #2 failed)
   Configure run after: has failed ☑
   Action: Compose
   Inputs: Error: @{outputs('Action_Name')?['error']?['message']}
   
5. (Error Notification - part of error path)
   Configure run after: is successful ☑ (success of previous error path action)
   Action: Send email
   To: admin@company.com
   Subject: Flow Failed - BC Integration
   Body: 
     Flow: @{workflow()?['name']}
     Run: @{workflow()?['run']?['name']

Key Points:

• Error path only runs if main action fails

• Error notification sends detailed diagnostic info

• Success path continues normal processing

Scope Action for Grouped Error Handling

For multiple actions, use "Scope" to group them and handle errors collectively:

Flow Structure:

Scope Benefits:

• One error handler for multiple actions

• Clear visual organization

• Easier to manage complex flows

• Better run history readability

Accessing Scope Results:

Try-Catch-Finally Pattern

Implement traditional programming error handling:

Flow Structure:

Benefits:

• Familiar pattern for developers

• Ensures cleanup always occurs

• Clear separation of concerns

Retry Policies

Power Automate automatically retries failed actions:

Default Retry Policy:

• 4 retries over 24 hours

• Exponential backoff (increasing delays)

• Automatic for transient failures

Custom Retry Policy:

1. Click action settings ("..." menu)

2. Select "Settings"

3. Configure:

   • Retry Policy: Exponential (default) or Fixed interval

   • Retry Count: 0-90 retries

   • Retry Interval: PT5S (5 seconds), PT1M (1 minute), etc.

   • Timeout: PT1M (1 minute) to PT1H (1 hour)

Example: Aggressive Retry for Critical Actions

Example: No Retry for Idempotent Actions

⚠️ WARNING: Too many retries can cause duplicate actions. Only retry actions that are idempotent (safe to repeat) or have duplicate detection logic.

Accessing Error Information

When an action fails, error details are available:

Error Message:

outputs('Action_Name')?['error']?['message']

Error Code:

outputs('Action_Name')?['error']?['code']

Complete Error Object:

outputs('Action_Name')?['error']

Example Error Notification:

Action: Send email (in error path)
Subject: Flow Failed - @{workflow()?['name']}
Body:
  Flow Name: @{workflow()?['name']}
  Run ID: @{workflow()?['run']?['name']}
  Failed Action: @{actions('Action_Name')?['name']}
  Error Code: @{outputs('Action_Name')?['error']?['code']}
  Error Message: @{outputs('Action_Name')?['error']?['message']

This provides complete context for troubleshooting.

Dead Letter Queue Pattern

For critical integrations, implement a dead letter queue (DLQ):

Concept:

• When flow fails repeatedly, log to special storage

• Manual intervention required

• Prevents data loss

Flow Structure:

Manual DLQ Processing:

• Admin reviews DLQ entries periodically

• Fixes underlying issues

• Re-triggers flow manually or via script

• Updates DLQ entry status to Processed

Testing Error Handling

Test Scenarios:

1. Test with Invalid Data

• Send webhook with missing required field

• Verify error path executes

• Verify error notification sent

2. Test with Unreachable Service

• Temporarily change SharePoint site URL to invalid

• Trigger flow

• Verify retries occur

• Verify error handling activates

3. Test Timeout

• Add "Delay" action set to 5 minutes in main scope

• Set scope timeout to 1 minute

• Trigger flow

• Verify timeout error handling

4. Test Partial Success

• Create flow with 3 actions

• Make second action fail (invalid config)

• Verify first action completed

• Verify third action skipped

• Verify error handling executed

💡 TIP: Create a test flow with deliberate errors to verify your error handling logic works before deploying to production. Use "Terminate" action with status "Failed" to simulate errors.

This completes Chapter 5. You now understand how to create robust Power Automate flows with proper data parsing, common integration patterns, and comprehensive error handling.