Service Bus for Workflows
Azure Service Bus is the brokered messaging service to reach for when an Entra-adjacent system needs reliable workflow coordination rather than raw streaming throughput. It is a strong fit when messages represent commands, work items, or workflow steps that must be processed with more control over delivery behavior.
Use Service Bus when delivery semantics matter more than replayable event streams.
The Brokered Messaging Model
Service Bus gives you a messaging layer built around explicit coordination features:
- Queues for point-to-point work distribution.
- Topics and subscriptions for controlled fan-out where different consumers receive their own routed copies.
- Dead-lettering for messages that cannot be processed successfully and need inspection or remediation.
- Sessions for ordered handling of related messages that belong to the same workflow or entity.
- Locks, retries, and settlement semantics so consumers can coordinate completion more safely than with simpler queues.
That feature set makes Service Bus appropriate for business workflows and operational tasks where message handling is part of the system contract.
Where It Fits Around Entra
Common Entra-adjacent examples include:
- onboarding commands that must reach downstream systems in sequence,
- remediation tasks created after Graph detects drift,
- approval or provisioning steps that require retries and inspection,
- worker coordination where a failed step must move to a dead-letter queue instead of disappearing into the stream.
In these systems, the message is not just telemetry. It is a unit of work with ownership and consequences.
Queues, Topics, And Subscriptions
Use queues when exactly one worker should handle each work item. Use topics and subscriptions when multiple downstream processes each need their own filtered copy of the workflow message.
The distinction matters because workflow fan-out is not the same as event-stream fan-out. In Service Bus, each subscription is still a broker-managed workflow surface with its own delivery lifecycle, retries, and dead-letter queue.
Why Dead-Lettering And Sessions Matter
Two features especially matter for identity workflows:
- Dead-lettering prevents poison or repeatedly failing messages from blocking the main queue forever. Operators can inspect them, fix the root cause, and decide how to recover.
- Sessions let related messages stay ordered for a shared key such as a tenant, user, connector, or onboarding case. That is often simpler than rebuilding ordering guarantees in application code.
These are strong reasons to choose Service Bus over simpler storage-backed queues when the workflow has real delivery requirements.
Service Bus vs Event Hubs
Service Bus and Event Hubs solve adjacent but distinct problems.
- Use Service Bus for commands, work items, controlled fan-out, retries, sessions, and dead-letter handling.
- Use Event Hubs for high-throughput event streams, retention-based replay, and multiple independent consumers reading the same flow.
If the message means “someone must complete this workflow step,” Service Bus is usually right. If the message means “here is another event in a large stream,” use Event Hubs for Identity Events instead.
Practical Trade-Offs
Service Bus is not the cheapest or simplest option, and that is fine. You choose it when the workflow contract justifies the extra broker features.
It is a weaker fit when:
- the main problem is stream throughput,
- consumers need replay over retained history,
- multiple analytics pipelines need to reread the same raw event stream,
- the workload is simple enough for a lightweight queue.
In those cases, Event Hubs or Azure Queue Storage may fit better.
Typical Placement
In this topic’s stack, Service Bus usually sits between Graph-driven decisions and worker execution:
- Graph or a function decides that work must happen,
- a queue or topic carries the workflow step,
- workers process the message,
- Cosmos DB or Storage keeps supporting state and artifacts,
- operators inspect dead-lettered messages when the workflow fails.
That makes Service Bus the reliable workflow coordinator in the architecture.