A Service Bus rule decides which topic messages land in a subscription. When a publisher sends one message to a topic, each subscription evaluates its rules. A rule can match everything, match message properties with a SQL-like expression, match exact correlation properties, or apply an action to change selected message properties. In plain terms, rules let one topic feed different consumers without every consumer receiving every event and writing its own filtering code. That keeps business routing close to the broker.
Azure Service Bus rule, topic subscription rule, Service Bus filter rule
Difficulty
fundamentals
CLI mappings
4
Last verified
2026-05-24
Microsoft Learn
A Service Bus rule is a named subscription rule on a topic subscription. It contains a filter condition, and optionally an action, so the subscription receives only matching topic messages or annotates selected messages before they are delivered to consumers.
Technically, rules sit under Service Bus topic subscriptions. They are data-plane routing configuration for publish-subscribe messaging, managed through the portal, Azure CLI, management SDKs, ARM, Bicep, or automation. A subscription starts with a default rule unless it is changed. Additional rules can use SQL filters, correlation filters, true filters, false filters, and optional SQL actions. The rule evaluation happens at the broker before consumers receive messages, so rules affect delivery, backlog shape, and subscription-level troubleshooting.
Why it matters
Rules matter because publish-subscribe systems become messy when every subscriber receives too much traffic. A well-designed rule lets an invoicing consumer receive only invoice events, a regional workflow receive only matching geography, or an exception handler receive only messages with a risk flag. That reduces application filtering code, lowers unnecessary processing, and makes subscription backlogs easier to interpret. Poor rules do the opposite: they drop messages silently, duplicate deliveries across subscriptions, create confusing default-rule behavior, and hide business routing inside fragile expressions. Operators need rule inventory and test evidence whenever topic routing changes. It also makes routing visible enough for release review and incident rollback.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Azure portal Subscription Filters page, each rule shows its name, filter type, SQL expression or correlation properties, and any configured action. during reviews.
Signal 02
In Azure CLI output, az servicebus topic subscription rule list returns rules beneath a specific namespace, topic, and subscription, including filter definitions and actions. regularly.
Signal 03
In deployment templates or release pipelines, rules appear as child configuration for topic subscriptions and usually include SQL filters, correlation filters, or default-rule removal. safely.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Route one topic into regional subscriptions without making every consumer parse all messages.
Remove a default catch-all rule so a subscription receives only explicitly approved events.
Create an exception subscription for high-risk orders, failed validations, or compliance flags.
Use correlation filters for exact-match routing on stable properties such as tenant, product, or event type.
Apply a rule action that stamps a downstream processing hint before a consumer receives the message.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A national insurance claims platform published all claim-status events to one topic. Fraud analysts needed suspicious claims quickly, but their consumer processed every routine claim event before finding the few that mattered.
🎯Business/Technical Objectives
Route high-risk claim events without changing every publisher.
Reduce fraud-review backlog during storm-related claim surges.
Keep routine claims flowing to existing consumers.
Make routing evidence clear enough for compliance review.
✅Solution Using Service Bus rule
Architects added a dedicated subscription for fraud review and created Service Bus rules that matched riskScoreBand and claimType application properties. They removed the default catch-all rule from the fraud subscription after testing sample messages from each claims system. A second rule captured claims from high-loss regions during declared disaster periods. Rule definitions were stored with the topic deployment template, and Azure CLI exported rules before and after the release. Fraud workers received only matched messages, while billing, notifications, and document workflows kept their existing subscriptions. Monitoring compared topic input with subscription output to catch accidental overmatching.
📈Results & Business Impact
Fraud-review backlog during surge periods dropped from 41,000 messages to 6,800 targeted events.
Analyst first-review time improved from 19 hours to 3.2 hours.
No publisher code changed because routing used existing message properties.
Compliance reviewers received rule exports and sample-message tests for every routing condition.
💡Key Takeaway for Glossary Readers
A Service Bus rule can turn broad topic fan-out into precise operational routing without rewriting producers.
Case study 02
Smart building platform routes tenant maintenance alerts
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A smart building platform managed elevators, HVAC units, and access-control devices for multiple property managers. Tenant support teams complained that topic subscriptions mixed urgent device alarms with routine telemetry notifications.
🎯Business/Technical Objectives
Deliver only tenant-specific maintenance alerts to each property manager.
Keep routine telemetry out of human support queues.
Reduce missed elevator and access-control alarms.
Document routing logic for onboarding new buildings.
✅Solution Using Service Bus rule
The integration team standardized message properties for buildingId, tenantId, deviceClass, and severity. Each property manager subscription received Service Bus rules using correlation filters for tenantId and SQL filters for severity and deviceClass combinations. The default rule was removed from support subscriptions so routine telemetry was not delivered. Rule actions stamped a supportQueueHint property for downstream ticket creation. Azure CLI release steps listed existing rules, created new rules, and exported final definitions into the onboarding package. Support dashboards showed subscription message counts by tenant so the team could catch routing drift after new buildings were added.
📈Results & Business Impact
Support subscriptions received 88 percent fewer routine telemetry messages.
Missed urgent device alarms fell from 17 in a month to one verified false negative.
New building onboarding time dropped from two days to six hours.
Property managers gained tenant-specific evidence showing which rules routed their alerts.
💡Key Takeaway for Glossary Readers
Rules are most useful when the broker can use stable message properties to protect each consumer from irrelevant traffic.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A maritime logistics hub published container movement events to a Service Bus topic. Customs brokers needed only holds, inspections, and missing-document events, but their application was overwhelmed by normal gate movements.
🎯Business/Technical Objectives
Isolate customs exception messages from normal movement events.
Reduce broker application CPU caused by application-side filtering.
Shorten response time for containers on regulatory hold.
Keep route changes reversible during a live port migration.
✅Solution Using Service Bus rule
Engineers created a customs-exceptions subscription and added Service Bus rules that matched eventType values for hold, inspectionRequested, and documentMissing. A SQL rule matched refrigerated containers with customsHold=true because those containers had stricter time limits. The deployment removed the default rule only after replaying sample messages through a staging topic. CLI commands captured every rule, filter expression, and subscription scope before cutover. Operations monitored topic input, customs subscription output, and broker application CPU for two weeks, then retired the old application-side filter configuration.
📈Results & Business Impact
Customs application CPU usage dropped by 57 percent after broker-side filtering.
Average time to assign a customs hold task improved from 74 minutes to 16 minutes.
No normal gate movement events reached the exception subscription after cutover.
Rollback remained one command because the previous rule export was stored with the release ticket.
💡Key Takeaway for Glossary Readers
A Service Bus rule keeps high-value exception workflows visible by preventing ordinary topic traffic from drowning them out.
Why use Azure CLI for this?
I use Azure CLI for Service Bus rules because subscription routing needs proof, not screenshots. In real environments, one topic can have many subscriptions and each subscription can have several rules. The portal is fine for a quick look, but CLI lets me export every rule, compare expressions across environments, remove a stale default rule, and create a new filter during a controlled release. After years of incidents, I do not trust memory for broker routing. CLI output gives developers, operators, and auditors the exact SQL filter, correlation properties, action, and scope being used. It also avoids stale routing surprises during schema changes.
CLI use cases
List all rules for a subscription and export filter expressions before changing routing.
Create a SQL or correlation rule during a controlled release to add a new consumer path.
Delete the default rule after confirming specific routing rules match the intended messages.
Compare rule definitions between dev, test, and production to detect drift.
Show one rule to verify its action and filter type during a missing-message incident.
Before you run CLI
Confirm the namespace, topic, subscription, and rule name because rule commands are deeply scoped.
Validate the message properties and schema version the rule depends on before creating or replacing filters.
Export existing rules first, especially the default rule, because deletion can immediately change delivered messages.
Use least-privilege management access and avoid changing production routing without publisher and consumer owners present.
What output tells you
Filter type and expression show whether matching uses SQL, correlation properties, true filters, or false filters.
Rule actions reveal whether selected messages are annotated before delivery to the subscription consumer.
Rule names and timestamps help identify stale routing created for old consumers, migrations, or temporary incident handling.
Subscription scope confirms exactly which consumer backlog is affected by a rule change.
Mapped Azure CLI commands
Term-specific Azure CLI operations
direct
az servicebus topic subscription rule list --resource-group <resource-group> --namespace-name <namespace> --topic-name <topic> --subscription-name <subscription> --output json
az servicebus topic subscription rulediscoverIntegration
az servicebus topic subscription rule show --resource-group <resource-group> --namespace-name <namespace> --topic-name <topic> --subscription-name <subscription> --name <rule> --output json
az servicebus topic subscription rulediscoverIntegration
az servicebus topic subscription ruleremoveIntegration
Architecture context
Architecturally, a Service Bus rule is where topic fan-out becomes selective routing. I use it when producers should publish one business event and the broker should deliver different subsets to different consumers. Rules belong in the integration contract: what properties publishers must set, which subscriptions depend on them, and what happens when a property is missing or renamed. They should be versioned with infrastructure code, tested with representative messages, and reviewed when schemas change. Rules are powerful, but they should not become hidden business logic that only one support engineer understands. Treat each rule as deployable infrastructure, not an afterthought inside the portal.
Security
Rule security is indirect but important. A rule does not authenticate callers, yet it determines which consumers receive which messages. A bad rule can route sensitive customer, payroll, location, or exception data to a subscription owned by the wrong team. Operators should restrict who can create, update, or delete subscription rules and should review message properties used for filtering. Rule actions can annotate properties that affect downstream processing, so they deserve the same change control as code. Sensitive routing decisions should be documented, monitored, and backed by least-privilege access to subscriptions. Audit logs should show who changed routing and why clearly.
Cost
Rules influence cost by controlling how many messages each subscription receives and how much downstream compute processes. A broad rule can multiply one published message into many unnecessary deliveries, worker executions, logs, and retries. A precise rule can reduce application filtering and avoid processing messages that a consumer would discard anyway. Complex rule inventories also create operational cost because routing becomes harder to test and support. FinOps reviews should look at topic fan-out, subscription message counts, idle subscriptions, duplicate rules, and rules that route high-volume traffic to expensive consumers without business justification. This review should happen before adding another worker group to compensate.
Reliability
Rule reliability depends on accurate expressions, stable message properties, and safe deployment order. If a publisher changes a property name before a subscription rule is updated, consumers may stop receiving messages even though the topic is healthy. If a default rule is left in place, a subscription may receive far more messages than intended. Operators should test rules with sample messages, monitor subscription backlog and delivery count after changes, and keep rollback commands ready. Rules should be reviewed with schema versions because routing failures often look like missing consumers, not broker outages. Staged rollout should include sample messages that prove positive and negative matches.
Performance
Rule performance is tied to broker-side filtering, topic fan-out, subscription backlog, and downstream concurrency. Simple correlation filters are usually easier to reason about than complex SQL expressions, but design choice depends on message properties and routing needs. Too many broad or overlapping rules can increase delivery volume and make subscribers appear slow. A rule action can also change properties consumed by workers, so mistakes create processing delays. Operators should watch incoming topic messages, outgoing subscription messages, backlog growth, and rule changes together to understand whether performance pressure comes from routing or consumer capacity. Benchmark routing changes with representative message volume before peak traffic.
Operations
Operators manage rules by listing them, checking filter type, inspecting SQL expressions or correlation properties, and confirming actions. During incidents, they compare rule configuration with message samples to determine whether messages were not published, not matched, or not consumed. During releases, they create new rules, disable old routing, and remove default catch-all rules only after validation. Good operations include exporting rules before changes, naming rules by business condition, storing expressions in source control, and alerting when subscription counts change unexpectedly after a routing update. Every rule change should have an owner, test message, and rollback note recorded in the ticket.
Common mistakes
Leaving the default true rule in place, causing a subscription to receive every topic message unexpectedly.
Filtering on message body content instead of promoted application properties that the broker can evaluate.
Changing publisher property names without updating dependent SQL or correlation rules.
Using vague rule names that make production routing impossible to understand during an incident.