Chapter 2: Understanding Power Automate Integration

This chapter provides deep technical understanding of how Business Central and Power Automate communicate. You'll learn webhook concepts, HTTP protocols, JSON structure, authentication mechanisms, and security considerations. This knowledge is essential for designing robust, secure integrations and troubleshooting issues when they arise.

By the end of this chapter, you'll understand the underlying technology stack, be able to design efficient JSON payloads, and know how to secure your integrations appropriately.

2.1 How Power Automate Works with Business Central

The Integration Architecture

The Business Central to Power Automate integration uses a push-based architecture where Business Central actively sends data to Power Automate, rather than Power Automate polling Business Central for changes.

Architecture Components:

Data Flow Sequence:

1. Event Generation: User action in BC creates database event (INSERT/UPDATE/DELETE)

2. Event Detection: Rule Engine subscriber catches event

3. Trigger Matching: System identifies matching flow triggers

4. Condition Evaluation: Scenarios check if conditions are met

5. Payload Construction: JSON template populated with actual data

6. HTTP Request: HTTPS POST sent to webhook URL

7. Azure Reception: Power Automate service receives webhook

8. Flow Activation: Corresponding flow's HTTP trigger fires

9. Workflow Execution: Flow steps execute in sequence

10. Connector Actions: External services called as configured

11. Response Logging: HTTP response recorded in BC validation log

Key Architectural Principles:

Asynchronous: BC doesn't wait for flow completion, only HTTP acknowledgment Fire-and-Forget: BC operation completes regardless of flow success/failure Stateless: Each webhook is independent; no session maintenance Idempotent: Same event can be sent multiple times (flow should handle duplicates) Secured: HTTPS encryption plus webhook URL secrecy provides security

Communication Protocol (HTTP/HTTPS)

The integration uses HTTP POST requests over HTTPS (secure HTTP):

Why HTTP POST?

HTTP POST is the standard method for sending data to web services:

• POST: Submits data to be processed (vs. GET which retrieves data)

• Request Body: Data sent in POST body (JSON payload)

• Response Codes: Standard status codes indicate success/failure

• Universal: Every platform understands HTTP

HTTPS Security:

All communication uses HTTPS (HTTP over TLS/SSL):

• Encryption: Data encrypted in transit

• Certificate Validation: BC validates Power Automate's SSL certificate

• Prevents Eavesdropping: Data can't be intercepted and read

• Prevents Tampering: Data can't be modified in transit

📋 NOTE: Business Central on-premises must have a valid root certificate store to validate Azure's SSL certificates. Most Windows Server installations include these by default. Linux-based BC servers may need certificate configuration.

HTTP Request Anatomy

When BC sends data to Power Automate, it constructs a complete HTTP request:

Request Structure:

POST https://prod-27.westus.logic.azure.com/workflows/.../triggers/manual/paths/invoke?api-version=2016-06-01&sp=...&sv=... HTTP/1.1
Host: prod-27.westus.logic.azure.com
Content-Type: application/json
Content-Length: 187
User-Agent: BusinessCentral/1.0

{
  "orderNo": "SO-001",
  "customerName": "Alpine Ski House",
  "amount": 15450.00,
  "orderDate": "2025-12-01"
}

Request Components:

Request Line:

• Method: POST

• URL: Complete webhook URL with query parameters

• Protocol: HTTP/1.1

Headers:

• Host: Target server (Azure Logic Apps endpoint)

• Content-Type: application/json (tells server payload is JSON)

• Content-Length: Size of JSON body in bytes

• User-Agent: Identifies BC as the client (for Azure logging)

Body:

• The actual JSON payload with resolved placeholders

HTTP Response:

Power Automate responds with a standard HTTP response:

HTTP/1.1 202 Accepted
Content-Type: application/json
Date: Mon, 09 Dec 2025 10:30:45 GMT

{
  "status": "Accepted"
}

Common Response Codes:

• 200 OK: Request processed successfully

• 202 Accepted: Request accepted for processing (async)

• 400 Bad Request: Invalid JSON or malformed request

• 401 Unauthorized: Authentication failed (invalid webhook URL)

• 404 Not Found: Webhook URL doesn't exist

• 500 Internal Server Error: Power Automate service error

• 503 Service Unavailable: Azure temporarily unavailable

⚠️ WARNING: Power Automate typically returns 202 Accepted, not 200 OK. BC treats both as success. Don't be alarmed if validation logs show 202—this is normal and expected.

Request Timeout and Retry Behavior

Timeout Configuration:

BC waits a limited time for Power Automate to respond:

• Default Timeout: 30 seconds

• Timeout Triggers: HTTP client abandons request

• Logged as Error: Validation log shows timeout error

What Timeout Doesn't Mean:

Timeout means Power Automate didn't respond within 30 seconds. It does NOT mean:

• The webhook wasn't received (it might have been)

• The flow didn't run (it might be running)

• The flow failed (it might succeed later)

Timeouts usually indicate network issues or Azure service delays, not flow logic problems.

Retry Behavior:

The QUALIA Power Automate Integration App does NOT automatically retry failed HTTP requests:

• Each trigger event fires once

• If HTTP fails, it's logged as error

• No automatic retry mechanism built-in

Why No Auto-Retry?

• Avoid duplicate flow executions

• Prevent storm of retries during outages

• Let flow designers control retry logic in flows

Implementing Retries:

If you need retries:

Option 1: Schedule periodic job in BC to resend failed webhooks Option 2: Configure retry in Power Automate flow using scope and error handling Option 3: Use Azure Service Bus queue as intermediary (advanced pattern)

💡 TIP: For critical integrations, monitor the validation log and create alerts for errors. Consider implementing a "resend failed webhooks" report that administrators can run to manually trigger retries.

2.2 Webhook Concepts and Architecture

What Is a Webhook?

A webhook is an HTTP callback—a way for one application to provide real-time information to another application by making an HTTP POST request when an event occurs.

Traditional Polling vs. Webhooks:

Polling (Old Way):

• Inefficient: 99% of requests return "no"

• Delayed: Up to polling interval lag

• Resource intensive: Constant checking

Webhooks (Modern Way):

• Efficient: Only communicates when events occur

• Real-time: Instant notification

• Resource-friendly: No constant checking

Webhook URL Structure

The webhook URL contains several components that identify and authenticate the request:

Example URL Breakdown:

Components:

1. Protocol: https://

• Secure HTTP required

• Never use plain http:// (insecure)

2. Hostname: prod-27.westus.logic.azure.com

• Azure Logic Apps endpoint

• Geographic region encoded (westus = West US datacenter)

• prod-27 indicates production environment instance

3. Port: :443

• Standard HTTPS port

• Usually omitted but can be explicit

4. Workflow Path: /workflows/a1b2c3d4e5f6/triggers/manual/paths/invoke

• Unique workflow identifier

• Routes to specific flow

5. Query Parameters: ?api-version=2016-06-01&sp=...&sig=...

• api-version: Logic Apps API version

• sp: Permissions scope

• sig: Signature for authentication (like a password)

• sv: Service version

Security Implications:

The webhook URL itself provides authentication:

• No separate API key needed: URL contains embedded authentication token (sig parameter)

• Treat as secret: Anyone with URL can trigger flow

• Don't log publicly: Keep URLs out of public logs, code repositories, documentation

• Regenerate if exposed: If URL leaks, regenerate the trigger in Power Automate

📋 NOTE: Webhook URLs are stable—they don't change unless you regenerate the trigger or delete/recreate the flow. You can use the same URL indefinitely for a given flow.

Webhook Lifecycle

Creation:

1. Create flow in Power Automate

2. Add "When an HTTP request is received" trigger

3. Save flow

4. Power Automate generates unique webhook URL

5. Copy URL for use in Business Central

Usage:

1. Configure URL in BC flow trigger

2. BC sends webhooks to URL when events occur

3. Power Automate receives and processes

4. Continues until flow disabled or URL changed

Regeneration:

1. Edit flow in Power Automate

2. Click on HTTP trigger

3. Click "..." menu → Delete

4. Add new "When an HTTP request is received" trigger

5. Save flow

6. New URL generated

7. Update URL in Business Central

Expiration:

• Webhook URLs don't expire based on time

• URL becomes invalid if flow deleted

• URL becomes invalid if trigger removed

• URL remains valid indefinitely otherwise

⚠️ WARNING: If you delete and recreate a flow, you get a NEW webhook URL. Remember to update Business Central configuration with the new URL, or webhooks will fail with 404 Not Found errors.

Webhook Security Best Practices

Protecting Webhook URLs:

1. Store Securely:

• Keep URLs in BC configuration only

• Don't include in version control if exporting templates

• Redact URLs from screenshots and documentation

2. Limit Access:

• Only give configuration access to trusted administrators

• Use BC permission sets to control who can view/edit flow triggers

• Restrict who can export templates (URLs included)

3. Monitor Usage:

• Review validation log for unexpected patterns

• Alert on sudden spikes in webhook calls

• Investigate 401/404 errors (might indicate URL guessing attempts)

4. Validate in Flow:

• Add conditions in Power Automate to validate data

• Check expected field formats

• Reject suspicious payloads

5. Use IP Restrictions (Advanced):

• Azure Logic Apps can restrict to specific IP ranges

• Configure to accept only from known BC server IPs

• Requires Azure management portal access

IP Whitelisting Example:

If your BC server's public IP is 203.0.113.45:

1. In Azure portal, open Logic App

2. Navigate to Settings → Workflow settings

3. Configure Access control configuration

4. Add allowed IP range: 203.0.113.0/24

5. Save changes

Now only requests from that IP range are accepted.

💡 TIP: For high-security environments, consider using Azure API Management as a gateway. It provides additional security features like rate limiting, token validation, and request transformation.

2.3 JSON Payload Structure

JSON Fundamentals

JSON (JavaScript Object Notation) is the data format used to send information from Business Central to Power Automate.

Basic JSON Syntax:

Object (Key-Value Pairs):

{
  "orderNo": "SO-001",
  "amount": 15450.00
}

Data Types:

String (text in quotes):

"customerName": "Alpine Ski House"

Number (no quotes):

"amount": 15450.00

Boolean (true/false, no quotes):

"isRushed": true

Null (empty value):

"trackingNumber": null

Array (list of values):

"items": ["Item1", "Item2", "Item3"]

Nested Object (object within object):

{
  "order": {
    "number": "SO-001",
    "customer": {
      "name": "Alpine Ski House",
      "id": "C-10000"
    }
  }
}

JSON Rules:

• Property names must be in double quotes: "name" not name

• String values must be in double quotes: "value" not 'value'

• Numbers and booleans don't use quotes

• No trailing commas: {"a": 1, "b": 2} not {"a": 1, "b": 2,}

• Case-sensitive: "OrderNo" and "orderno" are different

Designing JSON Payloads for Flow Triggers

When creating flow triggers, you design a JSON template that defines what data to send:

Simple Flat Structure:

{
  "documentType": "Order",
  "documentNo": "[36:3]",
  "customerNo": "[36:2]",
  "customerName": "[36:79]",
  "orderDate": "[36:13]",
  "amount": [36:110],
  "status": "[36:5]"
}

Advantages:

• Easy to parse in Power Automate

• Simple placeholder replacement

• Straightforward troubleshooting

Nested Structure:

{
  "document": {
    "type": "Order",
    "number": "[36:3]",
    "date": "[36:13]",
    "amount": [36:110]
  },
  "customer": {
    "number": "[36:2]",
    "name": "[36:79]",
    "email": "[18:102]"
  }
}

Advantages:

• Logical grouping of related data

• Easier to understand structure

• Mirrors BC table relationships

Design Recommendations:

1. Use Descriptive Property Names:

// Good
"customerName": "Alpine Ski House"

// Poor
"cn": "Alpine Ski House"

2. Use Consistent Naming Convention:

// camelCase (recommended)
"orderNumber": "SO-001"
"customerName": "Alpine"

// PascalCase (also common)
"OrderNumber": "SO-001"
"CustomerName": "Alpine"

// snake_case (avoid, harder in flows)
"order_number": "SO-001"

3. Include Identifiers: Always include key identifiers for lookups:

{
  "orderNo": "[36:3]",          // Can look up in BC
  "customerNo": "[36:2]",       // Can link to CRM
  "itemNo": "[27:1]",           // Can check inventory
  "salespersonCode": "[13:1]"   // Can route notifications
}

4. Include Timestamps: Useful for sorting and filtering:

{
  "eventTimestamp": "[TIMESTAMP]",
  "orderDate": "[36:13]",
  "postingDate": "[36:14]"
}

5. Limit Payload Size:

• Keep payloads under 1 MB (Power Automate limit)

• Don't include entire documents or binary data

• Send references (IDs) rather than full details

• Let flow retrieve additional data if needed

📋 NOTE: Business Central placeholders always resolve to text strings in JSON, even for numbers. Omit quotes around numeric placeholders to get actual JSON numbers: "amount": [36:110] not "amount": "[36:110]" (which creates string "15450.00" instead of number 15450.00).

Placeholder to JSON Mapping

Understanding how BC placeholders map to JSON types:

Text Fields:

"customerName": "[36:79]"
→ "customerName": "Alpine Ski House"

Numeric Fields (without quotes):

"amount": [36:110]
→ "amount": 15450.00

Numeric Fields (with quotes):

"amount": "[36:110]"
→ "amount": "15450.00"

(String representation, harder to use in calculations)

Date Fields:

"orderDate": "[36:13]"
→ "orderDate": "2025-12-01"

(ISO 8601 date format)

Boolean Fields:

"blocked": "[18:39]"
→ "blocked": "Yes"  or  "blocked": ""

(BC booleans become "Yes"/"No" or blank strings)

For proper JSON boolean:

"blocked": [18:39]
→ "blocked": true  or  "blocked": false

(Omit quotes and BC converts appropriately)

Option Fields:

"status": "[36:5]"
→ "status": "Released"

(BC converts option value to text)

Code Fields:

"salespersonCode": "[36:29]"
→ "salespersonCode": "JR"

💡 TIP: Test your JSON payload structure by manually triggering the flow with sample data in Power Automate before connecting to BC. Use the "Test" feature with manual input to validate your JSON structure is correct.

Handling Special Characters and Encoding

JSON has special characters that must be escaped:

Characters Requiring Escaping:

• Quotes: " becomes \"

• Backslash: \ becomes \\

• Newline: Line break becomes \n

• Tab: Tab character becomes \t

Example:

If customer name contains quotes:

Business Central: She said "Hello"
JSON: "customerName": "She said \"Hello\"

Business Central's Handling:

BC automatically escapes special characters when constructing JSON:

• You don't need to manually escape in templates

• Placeholders resolve with proper escaping

• Resulting JSON is always valid

Unicode Characters:

BC handles international characters correctly:

"customerName": "Müller GmbH"
"city": "São Paulo"
"contact": "François"

UTF-8 encoding ensures proper transmission.

⚠️ WARNING: If placeholder values contain complex data (HTML, XML, JSON strings), they'll be escaped making them hard to parse. For such scenarios, consider using base64 encoding or sending references to data rather than data itself.

2.4 Authentication and Security

Webhook URL as Authentication

Unlike traditional APIs that require API keys, OAuth tokens, or username/password, Power Automate webhooks use the URL itself for authentication:

Built-in Authentication:

The webhook URL contains query parameters that authenticate the request:

The sig parameter is a cryptographic signature that:

• Proves the caller knows the secret

• Cannot be guessed or brute-forced

• Validates each request

How It Works:

1. Power Automate generates URL with embedded signature

2. Only those who have the URL can make valid requests

3. Azure validates the signature on each request

4. Invalid signatures result in 401 Unauthorized errors

Security Through Obscurity:

This approach relies on:

• URL Secrecy: URL kept confidential

• Cryptographic Strength: Signature is computationally secure

• HTTPS: Prevents URL interception

Limitations:

• Anyone with the URL can trigger the flow

• No way to distinguish between legitimate BC calls and malicious ones (both use same URL)

• URL compromise requires regeneration (invalidates BC config)

Additional Authentication (Optional):

For higher security, add authentication in the flow itself:

Option 1: Shared Secret

Include a secret token in payload:

{
  "authToken": "MySecretToken123",
  "orderNo": "SO-001"
}

In Power Automate, add condition:

Option 2: IP Validation

Check the caller's IP address (available in HTTP trigger):

If triggerOutputs()['headers']['x-forwarded-for']

Option 3: Azure AD OAuth (Advanced)

Use Azure Active Directory authentication:

• Requires Azure AD app registration

• BC obtains bearer token before each request

• Flow validates token

• Most secure but most complex

💡 TIP: For most Business Central integrations, webhook URL security is sufficient. Add additional authentication for internet-exposed flows or high-security requirements.

Data Privacy and Compliance

When integrating BC with Power Automate, consider data privacy regulations:

GDPR Considerations:

1. Data Minimization: Only send data necessary for the integration:

// Good - only essential fields
{
  "orderNo": "SO-001",
  "amount": 15450.00
}

// Poor - excessive data
{
  "orderNo": "SO-001",
  "amount": 15450.00,
  "customerSSN": "123-45-6789",     // Sensitive
  "creditCardLast4": "4532",        // Not needed
  "personalNotes": "..."            // Private
}

2. Data Residency: Power Automate flows run in Azure regions:

• Flows inherit region from environment

• Data may cross borders during processing

• Check your organization's data residency requirements

• Consider using specific Azure regions

3. Retention: Flow run history retains data for 28 days:

• Input/output data stored in Azure

• Cannot be deleted early

• Factor into data retention policies

4. Right to be Forgotten: If customer requests data deletion:

• Delete from Business Central (source)

• Be aware data exists in flow history for up to 28 days

• Document this in privacy policies

Industry-Specific Regulations:

HIPAA (Healthcare):

• Use Power Automate in HIPAA-compliant environments

• Ensure Business Associate Agreement in place

• Consider PHI in webhook payloads

PCI DSS (Payment Cards):

• Never send full credit card numbers in webhooks

• Never send CVV codes

• Use tokens or last-4-digits only

SOX (Financial):

• Maintain audit trails (validation log)

• Implement segregation of duties

• Document integration controls

📋 NOTE: Consult your organization's compliance and legal teams before integrating Business Central with Power Automate, especially if handling sensitive data. This manual provides technical guidance, not legal advice.

Network Security

Firewall Configuration:

Business Central must reach Power Automate:

Outbound HTTPS Required:

• Protocol: HTTPS (TCP port 443)

• Destination: *.logic.azure.com

• Direction: Outbound from BC server

Firewall Rules:

No Inbound Ports Needed:

• BC initiates connections outbound only

• Power Automate doesn't connect back to BC

• No need to expose BC to internet

Proxy Configuration:

If BC uses HTTP proxy:

On-Premises: Configure proxy in BC service config:

<add key="HttpClientProxyUri" value="http://proxy.company.com:8080" />

SaaS: Microsoft manages; no configuration needed

Certificate Validation:

BC validates Power Automate's SSL certificate:

• Requires trusted root CA certificates

• Windows Server: Usually pre-configured

• Linux BC: May need certificate bundle installation

DMZ Considerations:

If BC is in DMZ:

• Allow DMZ → Internet HTTPS

• Document exception for security team

• Consider using Azure ExpressRoute for private connectivity (enterprise)

2.5 Flow Triggers and Actions in Power Automate

HTTP Trigger Configuration

The "When an HTTP request is received" trigger is the entry point for BC webhooks:

Trigger Properties:

HTTP POST URL:

• Automatically generated when flow is saved

• Copy this URL to BC flow trigger configuration

• Regenerates if trigger deleted/recreated

Request Body JSON Schema:

• Optional but highly recommended

• Defines expected JSON structure

• Enables dynamic content in flow

• Power Automate validates incoming JSON against schema

Who can trigger the flow:

• Typically "Anyone" for BC integrations

• Can restrict to specific connections (advanced)

Relative path (optional):

• Can add custom path segments to URL

• Extract path parameters

• Advanced scenario for routing multiple events to one flow

Generating JSON Schema:

Method 1: Use Sample Payload

1. In HTTP trigger, click "Use sample payload to generate schema"

2. Paste example JSON:

{
  "orderNo": "SO-001",
  "customerName": "Test Customer",
  "amount": 15450.00
}

3. Click "Done"

4. Schema automatically generated

Method 2: Provide Schema Manually

Paste JSON schema:

{
  "type": "object",
  "properties": {
    "orderNo": {"type": "string"},
    "customerName": {"type": "string"},
    "amount": {"type": "number"}
  }
}

Why Use Schema?

Benefits:

• Type validation (Power Automate rejects invalid JSON)

• IntelliSense in flow designer (autocomplete field names)

• Dynamic content tokens (easy access to fields)

• Documentation (schema describes expected data)

Without schema:

• Must parse JSON manually using "Parse JSON" action

• No automatic type checking

• Harder to reference fields in actions

💡 TIP: Always define JSON schema. It takes 30 seconds and saves hours of troubleshooting invalid payloads and parsing errors.

Common Flow Actions

After the HTTP trigger receives data from BC, flows typically perform actions:

Send Email:

Office 365 Outlook - Send an email (V2)

To: sales@company.com
Subject: New Order @{triggerBody()?['orderNo']}
Body: 
  Order Number: @{triggerBody()?['orderNo']}
  Customer: @{triggerBody()?['customerName']}
  Amount: $@{triggerBody()?['amount']

Create Record:

SharePoint - Create item

Site Address: https://company.sharepoint.com/sites/Sales
List Name: Orders
Title: @{triggerBody()?['orderNo']}
Customer: @{triggerBody()?['customerName']}
Amount: @{triggerBody()?['amount']

Post Message:

Microsoft Teams - Post message in a chat or channel

Team: Sales Team
Channel: Orders
Message:
  New order received!
  Order: @{triggerBody()?['orderNo']}
  Customer: @{triggerBody()?['customerName']}
  Amount: $@{triggerBody()?['amount']

Conditional Logic:

Condition - Control

If @{triggerBody()?['amount']

Call HTTP Endpoint:

HTTP - Premium

Method: POST
URI: https://api.crm.com/orders
Headers:
  Authorization: Bearer TOKEN
  Content-Type: application/json
Body:
{
  "externalId": "@{triggerBody()?['orderNo']}",
  "customer": "@{triggerBody()?['customerName']

✅ EXAMPLE - Complete Flow:

Scenario: Order Notification with Approval

Trigger: When HTTP request received (from BC)

Action 1: Condition - Check if amount > $10,000

If Yes:

• Action 2: Start and wait for approval

  • Title: "Approve Order @{triggerBody()?['orderNo']}"

  • Assigned to: manager@company.com

  • Details: Customer @{triggerBody()?['customerName']}, Amount $@{triggerBody()?['amount']}

• Action 3: Condition - Check approval outcome

  • If Approved:

    • Send email to sales: "Order approved"

  • If Rejected:

    • Send email to sales: "Order rejected"

If No:

• Action 2: Send email to sales

  • Subject: "Order @{triggerBody()?['orderNo']} received"

  • Body: Standard order confirmation

Action 4: Create SharePoint item (runs regardless of approval)

• List: All Orders

• Title: @{triggerBody()?['orderNo']}

• Status: If approved then "Approved" else "Pending"

This flow handles high-value orders differently from standard orders, all triggered automatically from Business Central.

This completes Chapter 2. You now have deep understanding of how BC and Power Automate communicate, webhook architecture, JSON structure, security considerations, and Power Automate flow basics.