Service Bus Integration with Logic Apps

Azure Logic Apps integrates with Azure Service Bus through a set of built-in connectors that enable no-code and low-code workflows. These connectors allow Logic Apps to trigger on incoming messages, send messages, peek messages, complete or abandon them, and manage dead-letter queues — all through a visual designer without writing application code. Logic Apps Service Bus integration is ideal for orchestrating workflows that connect Service Bus with other Azure services, databases, APIs, and third-party SaaS platforms.

Integration Architecture

TRIGGER — Logic App starts when a message arrives:

[Service Bus Queue / Subscription]
       |
       | message arrives
       v
[Logic App - Service Bus Trigger]
       |
       | steps execute sequentially
       v
[Send Email] [Call HTTP API] [Insert into SQL] [Post to Teams]


OUTPUT — Logic App sends a message to Service Bus:

[HTTP Request / Timer / Event Grid / Blob event]
       |
       v
[Logic App]
       |
       | "Send message" action
       v
[Service Bus Queue / Topic]

Available Service Bus Actions and Triggers in Logic Apps

Use Case 1 — Order Notification Workflow

When a new order message arrives in the orders queue, send an email notification, log the order to a SQL database, and complete the message.

Workflow:
  Trigger : "When a message arrives in orders queue (peek-lock)"
      |
      +--> Action: "Parse JSON" (parse message body)
      |
      +--> Action: "Send an email (Outlook / SendGrid)"
      |       To      : customer@email.com
      |       Subject : "Order Confirmed: #{{orderId}}"
      |       Body    : "Your order for {{product}} is confirmed."
      |
      +--> Action: "Insert row (SQL Server / Azure SQL)"
      |       Table : Orders
      |       Data  : orderId, product, amount, timestamp
      |
      +--> Action: "Complete the message in orders queue"
              Lock Token: {{triggerBody().lockToken}}

Visual Flow Diagram

+--------------------------------------------+
| Trigger: Message in "orders" queue         |
+--------------------------------------------+
               |
               v
+--------------------------------------------+
| Action: Parse JSON                         |
| Schema: { orderId, product, amount }       |
+--------------------------------------------+
               |
       +-------+--------+
       |                |
       v                v
+-------------+  +------------------+
| Send Email  |  | Insert SQL Row   |
| (SendGrid)  |  | (Azure SQL)      |
+-------------+  +------------------+
       |                |
       +-------+--------+
               |
               v
+--------------------------------------------+
| Action: Complete message in "orders" queue |
+--------------------------------------------+

Use Case 2 — HTTP API to Service Bus Bridge

Accept an HTTP request, validate the payload, and put a message on the Service Bus queue. Downstream services consume from the queue asynchronously.

Trigger : "When HTTP request is received"
  Method : POST
  URL    : https://prod-01.eastus.logic.azure.com/workflows/.../triggers/manual/paths/invoke

Action 1: "Condition" — validate payload
  Expression: "@not(equals(triggerBody()?['orderId'], null))"

  If TRUE:
    Action 2: "Send message" to Service Bus
      Queue        : orders
      Content      : @{triggerBody()}
      Message ID   : @{triggerBody()?['orderId']}
      Content Type : application/json
      Properties   :
        Region      : @{triggerBody()?['region']}
        Priority    : High

    Action 3: "Response" -- HTTP 202 Accepted
      Status : 202
      Body   : { "status": "queued", "orderId": "@{triggerBody()?['orderId']}" }

  If FALSE:
    Action 4: "Response" -- HTTP 400 Bad Request
      Status : 400
      Body   : { "error": "orderId is required" }

Use Case 3 — Dead Letter Queue Monitor

On a timer schedule, check the DLQ for any messages. If messages exist, send an alert to Microsoft Teams and a summary email to the operations team.

Trigger : Recurrence (every 15 minutes)

Action 1: "Get messages from orders/$DeadLetterQueue"
  Count: 10

Action 2: "Condition" — check if any DLQ messages found
  Expression: "@greater(length(body('Get_messages')?['value']), 0)"

  If TRUE:
    Action 3: "Post message (V3) in Teams channel"
      Team    : Ops Team
      Channel : #alerts
      Message : "ALERT: {{length}} dead-lettered messages in orders queue!"

    Action 4: "Send email"
      To      : ops-team@company.com
      Subject : "Service Bus DLQ Alert"
      Body    : "{{length}} messages in DLQ. Check Service Bus immediately."

    Action 5: For each DLQ message:
      Sub-Action: "Dead-letter the message" (acknowledge reading it)

  If FALSE:
    (No action — DLQ is empty)

Use Case 4 — Topic Fan-Out to Multiple Systems

A Logic App receives an order event from a Service Bus topic subscription and fans it out to three external systems: a CRM (Salesforce), a fulfillment API (HTTP), and a notification service (Twilio SMS).

Trigger : "When a message arrives in order-events/inventory-sub"

Action 1: "Parse JSON" (order event body)

Action 2: "Create record" (Salesforce)
  Object  : Order__c
  Fields  : OrderId, CustomerId, Amount, Region

Action 3: "HTTP" (call fulfillment API)
  Method  : POST
  URI     : https://fulfillment.company.com/api/orders
  Body    : @{body('Parse_JSON')}

Action 4: "Send Text Message (V2)" (Twilio SMS)
  To      : @{body('Parse_JSON')?['customerPhone']}
  Body    : "Your order #@{body('Parse_JSON')?['orderId']} is being processed."

Action 5: "Complete the message in order-events/inventory-sub"

Creating a Logic App Service Bus Connection

1. Open Azure Portal and create or open a Logic App
2. In the designer, search for Service Bus in the connector search
3. Select a trigger or action
4. Click Add new connection
5. Enter a connection name (e.g., myshopns-connection)
6. Paste the Service Bus connection string from the namespace
7. Click Create

Managed Identity Connection (Standard Logic App)

Standard Logic Apps support Managed Identity for Service Bus connections.

1. Enable System Assigned Managed Identity on the Logic App
2. Assign "Azure Service Bus Data Receiver" role to the Managed Identity
   on the Service Bus namespace or specific queue
3. In the Service Bus connection, select "Managed Identity" authentication
4. No connection string needed — no secrets to rotate

Message Properties Available in Logic Apps

Polling Interval — Trigger Frequency

The Service Bus trigger in Logic Apps uses a polling model. The Logic App periodically checks the queue for new messages. The minimum polling interval is 1 second for Standard Logic Apps and 1 minute for Consumption Logic Apps.

Logic Apps vs Azure Functions for Service Bus

Best Practices

• Always use peek-lock trigger mode — Receive-and-delete deletes the message before your workflow finishes
• Always end the workflow with Complete or Abandon — never leave messages locked indefinitely
• Use Managed Identity on Standard Logic Apps to avoid connection string secrets
• Use Configure retry policy on each action to handle transient failures in downstream services
• Monitor Logic App run history in the portal to review failures and replay failed runs
• Set a Timeout on the workflow to prevent indefinitely stuck runs from holding message locks
• For high-volume queues (>1000 messages/minute), prefer Azure Functions — Logic Apps polling is not designed for high throughput

Summary

Azure Logic Apps integrates with Service Bus through built-in connectors that require zero custom code. Triggers automatically start a workflow when a message arrives in a queue or topic subscription. Actions allow sending messages, completing or abandoning locks, and reading from dead-letter queues. Logic Apps excels at orchestrating multi-step workflows that connect Service Bus to email, databases, APIs, Teams, Salesforce, and hundreds of other services. For high-throughput processing or complex business logic, Azure Functions is a better fit. For enterprise orchestration, approval workflows, and SaaS connectivity, Logic Apps with Service Bus is a powerful, maintainable, low-code solution.