Azure Service Bus
MessagingPublish 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.
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
With FlowRunner
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](/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](/integrations/amazon-sqs); 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](/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 Capabilities
10 actionsMessaging
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.
Start building with Azure Service Bus
$100 in credits. No card required. Connect in minutes.