Expert Azure Bot

An Azure Logic Apps specialist with deep expertise in Workflow Definition Language (WDL), enterprise integration patterns, and automation best practices for building reliable Azure-based automation workflows.

When to Use This Agent

Choose Expert Azure Bot when:

• Designing and building Azure Logic Apps workflows
• Implementing complex integration patterns (polling, batching, fan-out)
• Troubleshooting Logic Apps failures and performance issues
• Connecting Azure services with SaaS applications via Logic Apps connectors
• Migrating BizTalk or other integration platforms to Logic Apps

Consider alternatives when:

• Building Azure Functions (use a general Azure development agent)
• Managing Azure infrastructure (use an Azure architect agent)
• Working with non-Azure integration platforms (use the relevant platform agent)

Quick Start

Copy
# .claude/agents/expert-azure-bot.yml
name: Expert Azure Bot
description: Design and build Azure Logic Apps workflows
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - WebSearch

Example invocation:

claude "Design a Logic App that monitors a Service Bus queue, processes order messages, calls a REST API, and sends failure notifications via Teams"

Core Concepts

Logic Apps Workflow Patterns

Pattern	Use Case	Implementation
Sequential	Step-by-step processing	Actions in order
Parallel	Independent operations	Parallel branch
Fan-out/Fan-in	Process array items	For-each with concurrency
Polling	Monitor for changes	Recurrence trigger + condition
Retry	Handle transient failures	Retry policy on actions
Compensation	Undo on failure	Run-after with failure conditions

Workflow Definition (WDL)

Copy
{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "triggers": {
      "When_message_received": {
        "type": "ApiConnection",
        "inputs": {
          "host": { "connection": { "name": "@parameters('$connections')['servicebus']['connectionId']" } },
          "method": "get",
          "path": "/@{encodeURIComponent('orders')}/messages/head",
          "queries": { "queueType": "Main" }
        },
        "recurrence": { "frequency": "Second", "interval": 30 }
      }
    },
    "actions": {
      "Parse_Order": {
        "type": "ParseJson",
        "inputs": {
          "content": "@triggerBody()?['ContentData']",
          "schema": {
            "type": "object",
            "properties": {
              "orderId": { "type": "string" },
              "amount": { "type": "number" },
              "customerId": { "type": "string" }
            }
          }
        },
        "runAfter": {}
      },
      "Process_Order": {
        "type": "Http",
        "inputs": {
          "method": "POST",
          "uri": "https://api.example.com/orders/process",
          "body": "@body('Parse_Order')",
          "retryPolicy": {
            "type": "exponential",
            "count": 3,
            "interval": "PT10S",
            "maximumInterval": "PT1H"
          }
        },
        "runAfter": { "Parse_Order": ["Succeeded"] }
      },
      "Send_Failure_Notification": {
        "type": "ApiConnection",
        "inputs": {
          "host": { "connection": { "name": "@parameters('$connections')['teams']['connectionId']" } },
          "method": "post",
          "path": "/v3/beta/teams/@{encodeURIComponent('team-id')}/channels/@{encodeURIComponent('channel-id')}/messages",
          "body": {
            "body": { "content": "Order @{body('Parse_Order')?['orderId']} failed: @{body('Process_Order')}" }
          }
        },
        "runAfter": { "Process_Order": ["Failed", "TimedOut"] }
      }
    }
  }
}

Configuration

Parameter	Description	Default
logic_app_type	Logic Apps type (consumption, standard)	consumption
region	Azure region for deployment	Subscription default
integration_account	Integration account for B2B scenarios	None
retry_policy	Default retry policy for actions	Exponential, 3 attempts
concurrency_control	Max concurrent runs	25
diagnostic_logging	Enable diagnostic logs	true

Best Practices

1. Use Standard Logic Apps for production workloads that need VNET integration. Consumption Logic Apps are simpler and cheaper for low-volume workflows, but Standard Logic Apps (built on Azure Functions runtime) offer VNET integration, local development support, and stateful/stateless workflow options. For enterprise scenarios requiring private endpoints and network isolation, Standard is the right choice.

2. Implement compensating actions for every critical step. When a multi-step workflow fails halfway through (order created but payment failed), the system is in an inconsistent state. Configure runAfter conditions to trigger compensating actions on failure: cancel the order, refund the payment, or send an alert. Every action that modifies state should have a corresponding undo action.

3. Use managed identities instead of connection strings for Azure service authentication. Connection strings embedded in Logic Apps create security risks and rotation headaches. Managed identities provide automatic token management, no stored credentials, and Azure RBAC-based access control. Enable system-assigned managed identity on the Logic App and grant it the minimum required role on each connected resource.

4. Design for idempotency since Logic Apps may retry failed actions. With retry policies enabled, actions can execute multiple times for a single trigger. Ensure that API calls, database writes, and message publishes are idempotent — processing the same message twice should produce the same result, not duplicate records. Use unique message IDs and upsert operations.

5. Monitor with diagnostic settings and custom tracking. Enable diagnostic logging to Log Analytics for run history, trigger history, and action-level timing. Add trackedProperties to critical actions to log business-relevant data (order IDs, amounts) alongside the technical execution data. Set up alerts for failed runs, long-running executions, and throttled actions.

Common Issues

Logic App triggers fire multiple times for the same event. Some triggers (Service Bus, Event Grid) may deliver the same event multiple times during retries or rebalancing. Implement deduplication using the message ID: check a cache or database for the message ID before processing, skip if already processed. The Singleton pattern (concurrency = 1) prevents parallel processing but does not prevent duplicate triggers.

Workflows timeout on long-running operations. Logic Apps actions have a default timeout of 2 minutes (configurable up to 120 days for async patterns). For long-running API calls, implement the async polling pattern: the API returns a 202 with a status URL, and the Logic App polls until completion. This is natively supported via the AsyncPattern option on HTTP actions.

Connector throttling causes intermittent failures during high-volume processing. Each Logic Apps connector has rate limits (e.g., Office 365: 60 calls/minute). Processing a batch of 500 emails sequentially hits the limit quickly. Use the concurrency setting on For-Each loops to limit parallel calls. Implement queuing with Service Bus to smooth out burst traffic. Check connector-specific rate limits in the Microsoft documentation and design accordingly.