--- title: "Azure Service Bus Integration" description: "Publish and consume messages on Azure Service Bus. Agents send to queues and topics, receive reliably with peek-lock, complete or abandon deliveries, read topic subscriptions, and provision queues and topics in the namespace." url: https://flowrunner.ai/integrations/azure-service-bus date_modified: 2026-08-04T10:04:16-07:00 --- # Azure Service Bus [Messaging](https://flowrunner.ai/integrations/category/communication-messaging) Publish and consume messages on Azure Service Bus. Agents send to queues and topics, receive reliably with peek-lock, complete or abandon deliveries, read topic subscriptions, and provision queues and topics in the namespace. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 10 actions · Custom auth · available [Azure Service Bus website](https://learn.microsoft.com/) · [Platform Documentation](https://learn.microsoft.com/azure/service-bus-messaging/) · Capability data verified 2026-07-27 1. A scheduled consumer loop polls the order-events queue 2. Receive Message (Peek-Lock) retrieves and locks the next message without deleting it 3. Agent parses the payload and enriches the order against the ERP 4. Agent validates the message against the expected schema and business rules 5. An operations engineer reviews messages that fail validation before they are completed away, because a deleted message is the only copy of the event 6. Complete Message deletes cleanly processed messages via the lock location URI 7. Abandon Message releases the lock on transient failures so the broker redelivers 8. The processing summary posts with counts of completed, abandoned, and escalated messages ## What This Integration Enables Service Bus is where Azure architectures put the events that must not be lost: orders, provisioning commands, billing signals. The broker guarantees delivery; it says nothing about what happens next, and "what happens next" usually means writing another consumer service. This connector makes FlowRunner the consumer. Agents send messages with broker properties and custom metadata, receive with peek-lock semantics for at-least-once processing, complete or abandon deliveries explicitly, fan events in from topic subscriptions, and provision queues in the namespace. The connector takes delivery semantics seriously because the API does: the safe path and the fast path are different actions, chosen deliberately, not a flag someone forgets. That makes the delivery guarantee legible in the flow diagram itself. - Publish work to queues and events to topics with TTL, correlation, and session properties - Consume with peek-lock, completing on success and abandoning for redelivery on failure - Subscribe flows to topic fan-out without deploying subscriber services - Bridge non-Azure systems onto the bus and bus events into business tools - Provision and tear down queues as part of environment workflows ### Without FlowRunner **Queue consumers mean custom code**: Every new consumer of a queue is a service someone has to build, deploy, and babysit **Poison messages clog silently**: A malformed payload cycles through redelivery until someone notices the depth graph **The bus and the business tools cannot see each other**: Events flow between Azure services while spreadsheets, chat, and CRMs live in another universe ### With FlowRunner **Flows are consumers**: FlowRunner agents peek-lock, process, and complete messages with no service to deploy **Poison messages surface to people**: Validation failures pause on a lock and reach a human with the payload attached **The bus reaches the whole stack**: Bus events become Slack alerts, sheet rows, and CRM updates; stack events become bus messages ## Use Case Scenarios ### The consumer that is a flow, not a microservice Order events queue up from the commerce platform. A FlowRunner loop calls Receive Message (Peek-Lock), enriches each order, writes the result to [Airtable](https://flowrunner.ai/integrations/airtable), and calls Complete Message with the lock URI only after the write succeeds. If the enrichment source times out, Abandon Message releases the lock and the broker redelivers later. At-least-once processing, with the retry logic living in the broker where it belongs, and no consumer service on anyone's on-call rota. ### Cross-cloud bridging without glue code Part of the stack emits to [Amazon SQS](https://flowrunner.ai/integrations/sqs-service); the Azure side listens to Service Bus. A bridging flow receives from SQS and calls Send Message onto the Azure topic, carrying the CorrelationId through BrokerProperties so tracing survives the crossing. The reverse leg does the same in the other direction. Two message backbones behave as one, and the integration is a visible flow diagram instead of a Lambda nobody remembers deploying. ### Topic fan-out that includes humans Deployment events publish to a topic. Downstream services consume their subscriptions as always, and a FlowRunner agent consumes an ops subscription with Receive from Subscription: it posts each event to [Slack](https://flowrunner.ai/integrations/slack) with severity formatting, then completes the message. If the alert fails to send, the flow calls Abandon Message so the event redelivers rather than vanishing. The human channel gets the same delivery guarantees as the software consumers, which is the point. ## Human-in-Loop Highlight Delete Queue permanently removes a queue and every message still in it, and on a production bus those messages are unprocessed business events: orders not yet fulfilled, commands not yet executed. There is no undo and no recycle bin; the depth you deleted was the backlog. So FlowRunner environment-teardown flows never let an agent resolve "clean up the namespace" into deletions on its own. The agent inventories with List Queues, checks depth, and presents the docket: "Delete queue orders-staging-v2? It holds 1,240 messages, newest enqueued 3 hours ago." A person who knows whether staging is actually done answers first. The same judgment applies to choosing Receive and Delete Message over peek-lock: it is a standing decision that losing a message on failure is acceptable, so FlowRunner flows default to Receive Message (Peek-Lock) and use the destructive read only where a human has explicitly accepted at-most-once delivery. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 10 actions ### Messaging 6 - **Send Message** Sends a message to a queue or topic, with Label, TimeToLive, CorrelationId, and SessionId passed via BrokerProperties and application-defined values as custom properties. The publish verb for work and events. - **Receive Message (Peek-Lock)** Retrieves and locks the next queue message without deleting it, returning body, BrokerProperties, and a lock location URI. The at-least-once read that FlowRunner flows default to. - **Receive and Delete Message** Retrieves and immediately deletes the next message in one destructive read. Faster, but the message is gone even if the flow later fails; reserved for flows where at-most-once is an accepted decision. - **Receive from Subscription** Peek-locks the next message from a topic subscription, with the same complete-or-abandon contract. The way flows join a topic's fan-out. - **Complete Message** Deletes a peek-locked message via its lock location URI, confirming successful processing. The commit at the end of every safe consumer loop. - **Abandon Message** Releases a peek-lock so the message becomes available for redelivery. The failure path that turns errors into retries instead of losses. ### Management 4 - **List Queues** Lists the namespace's queues by name, with skip and top paging. The inventory read before any management decision. - **List Topics** Lists the namespace's topics by name, with skip and top paging. - **Create Queue** Creates a queue with optional maximum size, default message TTL, and duplicate detection. Fails if the name exists, which makes it safe to use idempotently in provisioning flows. - **Delete Queue** Permanently deletes a queue and all messages in it. Cannot be undone; gated behind human approval in every FlowRunner flow. ## Frequently Asked Questions ### What can FlowRunner do with Azure Service Bus? FlowRunner agents can run Send Message, Receive Message (Peek-Lock), and Receive and Delete Message in Azure Service Bus, plus 7 more actions. ### Does connecting Azure Service Bus to FlowRunner require OAuth? Azure Service Bus uses a custom authentication method to connect to FlowRunner. ### Can Azure Service Bus trigger a FlowRunner workflow automatically? Azure Service Bus doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Azure Service Bus?** This integration exposes Azure Service Bus to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/azure-service-bus. Site index: https://flowrunner.ai/llms.txt