A subscription rule is the message-selection logic on an Azure Service Bus topic subscription. A topic can receive many messages, but each subscription usually needs only some of them. Rules decide which messages flow into that subscription by checking properties such as event type, customer, priority, region, or correlation ID. A rule can use SQL-like expressions or faster correlation matching, and it can optionally stamp matching messages with actions. Good rules keep consumers focused. Bad rules create missing messages, duplicate processing, or dead-letter confusion.
Service Bus subscription rule, topic subscription filter rule, Service Bus rule filter
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-27T00:14:14Z
Microsoft Learn
A subscription rule in Azure Service Bus belongs to a topic subscription and selects which topic messages the subscription receives. Each named rule has a filter condition, such as SQL or correlation matching, and can optionally apply an action to matching messages.
In Azure architecture, subscription rules sit in the Service Bus data-plane messaging path between a topic and its subscriptions. Producers send messages to the topic. Each subscription evaluates its rules to decide which messages to store for that consumer group. Rules can be SQL filters, correlation filters, or default catch-all filters, and multiple matching rules without actions still result in one message copy for the subscription. Operators manage rules through portal, Azure CLI, ARM, SDKs, and automation while monitoring message counts, dead-letter queues, consumer lag, and processing errors.
Why it matters
Subscription rules matter because they determine which downstream system receives which business events. In a topic-based design, producers should not know every consumer. Rules let each subscriber express interest without changing producer code. That flexibility is powerful, but a small rule mistake can silently starve a billing processor, flood a fraud service, or send regulated messages to the wrong workflow. Rules also affect throughput, troubleshooting, and ownership. Operators need to know whether a consumer missed messages because none were published, because the filter excluded them, because the subscription was disabled, or because the processor failed. Rule clarity is essential for reliable event routing.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Service Bus topic subscription Filters page, rules appear with names, filter types, SQL expressions, correlation properties, and optional actions for matching messages and consumers.
Signal 02
In Azure CLI output for topic subscription rule list or show, the filterType, sqlExpression, correlation fields, and action settings reveal active routing logic for support review.
Signal 03
In consumer symptoms, a bad rule shows up as empty subscriptions, unexpected backlog, missing event types, duplicate downstream work, or dead-letter spikes after routing changes.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Route only high-priority order events to a fulfillment escalation worker without changing the publishing application.
Split messages by tenant, region, or product line so each processor receives the subset it owns.
Replace a broad default rule with named filters when a topic grows from one consumer to many specialized consumers.
Use correlation filters for exact-match event properties where SQL expressions are unnecessary and harder to maintain.
Debug missing downstream events by comparing published message properties with the active subscription rule filters.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Airline routes baggage exceptions without flooding operations
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An airline published baggage events to a Service Bus topic for tracking, compensation, and airport operations. The operations processor was receiving every event, including routine scans that it did not need.
🎯Business/Technical Objectives
Route only delayed, damaged, and missing-bag events to the operations subscription.
Keep routine scan events available for analytics without overloading human workflows.
Reduce processor backlog during peak holiday travel.
Make routing rules visible to support engineers during incidents.
✅Solution Using Subscription rule
Integration engineers created named subscription rules on the operations topic subscription for exception event types. A SQL filter matched eventType values for delayed, damaged, or missing baggage, and the team removed the old catch-all default rule after validating analytics had its own subscription. The producer contract was updated to document eventType and airportCode properties. CLI exports of the rules were stored with the integration deployment. Azure Monitor alerts watched active message count and dead-letter count for the operations subscription during the first holiday peak. A test message suite verified that routine scans no longer entered the human workflow queue.
📈Results & Business Impact
Operations subscription volume dropped 76% while exception messages continued to arrive within seconds.
Holiday backlog stayed below 1,200 active messages, down from 19,000 during the prior peak.
Support engineers resolved the first missing-message ticket in 14 minutes by comparing rule output to sample properties.
No compensation workflow outage occurred during the routing change.
💡Key Takeaway for Glossary Readers
Subscription rules keep topic-based systems scalable by letting each consumer receive the business events it actually owns.
Case study 02
Manufacturer isolates quality alerts from machine telemetry
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A precision manufacturing plant sent machine telemetry and quality events through one Service Bus topic. The quality-control application was wasting compute reading temperature and vibration messages that never required inspection.
🎯Business/Technical Objectives
Deliver only failed-inspection and tolerance-drift events to quality control.
Keep high-volume machine telemetry available for data science consumers.
Reduce unnecessary function executions in the quality application.
Create a repeatable pattern for future production lines.
✅Solution Using Subscription rule
The integration team added correlation filter rules to the quality subscription because the producer already stamped stable lineId and eventClass properties. Rules were created for eventClass values FailedInspection and ToleranceDrift, with separate names for each production line. The default rule was removed after replay tests proved analytics and maintenance consumers had their own subscriptions. CLI commands listed rule definitions before and after deployment, and a small test publisher sent known messages to verify routing. The team documented correlation properties in the event schema repository so new lines could copy the pattern without inventing different property names.
📈Results & Business Impact
Quality-control function executions fell 68% in the first week after routing changed.
Average inspection alert latency improved from 41 seconds to 9 seconds during peak shifts.
Data science telemetry ingestion was unaffected because it used a separate catch-all subscription.
Three new production lines adopted the same rule pattern with no custom routing code.
💡Key Takeaway for Glossary Readers
Subscription rules are most effective when message properties are treated as a stable contract between producers and consumers.
Case study 03
Insurance platform separates fraud review from routine claims
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An insurance claims platform used Service Bus topics to fan out claim events. The fraud review processor was overloaded because it received routine low-risk claim updates and duplicate adjustment events.
🎯Business/Technical Objectives
Send only high-risk or manually flagged claim events to fraud review.
Avoid changes to the core claims publishing service during a busy enrollment season.
Reduce dead-letter growth caused by the fraud processor rejecting irrelevant messages.
Give auditors a readable routing rule for sensitive claim workflows.
✅Solution Using Subscription rule
Architects defined a SQL filter rule on the fraud subscription using claimRiskScore and manualReviewRequired message properties. The rule selected high-risk claims or claims explicitly marked for manual review. An action stamped a routeReviewed property so downstream logs could show the message had passed the fraud-routing rule. The team deleted a legacy broad rule only after replaying sample messages from the previous week. CLI output for rule show was attached to the change request, and monitoring separated fraud subscription backlog from the broader claims topic. Auditors received the rule expression and event-property documentation.
Dead-letter count dropped from 3,400 messages per week to fewer than 300.
No publisher deployment was required during enrollment season.
Audit review time for claims routing evidence fell from six hours to one hour.
💡Key Takeaway for Glossary Readers
A well-named subscription rule can be both routing logic and audit evidence for sensitive event-driven workflows.
Why use Azure CLI for this?
After years of operating Service Bus in production, I use CLI for subscription rules because filters need exact text, repeatable review, and quick comparison. The portal is helpful, but copying SQL expressions by hand is error-prone during incidents. CLI lets me list rules, show the active filter, create a correlation or SQL rule, delete a stale default rule, and capture the configuration in a change record. It also works well in release pipelines when routing rules change with an event contract. CLI will not prove the business expression is correct, but it gives engineers a disciplined way to inspect and change the actual rule the broker evaluates.
CLI use cases
List rules on a topic subscription before changing a consumer routing contract.
Create a SQL filter rule for a specific event type or priority property during an integration rollout.
Create a correlation filter rule for exact tenant, session, label, or correlation ID matching.
Show a rule to confirm the broker is evaluating the expected filter expression.
Delete a stale default or legacy rule after confirming no consumer still depends on catch-all routing.
Before you run CLI
Confirm tenant, subscription, resource group, namespace, topic, subscription name, rule name, and the exact message properties the producer sends.
Verify data-plane and control-plane permissions, especially who can change rules on production topics that feed critical consumers.
Test SQL expressions or correlation properties in nonproduction, and know whether deleting a default rule changes catch-all behavior.
Capture current rules before mutation so rollback can recreate the previous filters and actions quickly.
What output tells you
The rule name identifies the routing contract, while filterType tells you whether SQL or correlation matching is being used.
SQL expression output shows the exact property conditions the broker evaluates before a message enters the subscription.
Correlation fields show exact-match properties such as correlationId, subject, contentType, or custom application properties.
Action output matters because matching messages can be annotated before consumers receive them, changing downstream assumptions.
Mapped Azure CLI commands
Service Bus subscription rule commands
direct
az servicebus topic subscription rule list --resource-group <resource-group> --namespace-name <namespace> --topic-name <topic> --subscription-name <subscription> --output table
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-name>
az servicebus topic subscription rulediscoverIntegration
az servicebus topic subscription ruleremoveIntegration
Architecture context
As an Azure architect, I treat subscription rules as part of the event-routing contract, not as a convenience setting. Producers publish stable message properties, and each consumer owns rules that describe the subset it can process. Correlation filters are preferable for simple exact matches because they are efficient and easier to reason about. SQL filters are useful for richer property expressions, but they need tests and naming discipline. Rules should be deployed alongside subscription infrastructure, versioned with the event schema, and monitored with subscription backlog and dead-letter metrics. A clean design avoids one giant topic becoming an undocumented integration switchboard that nobody can debug.
Security
Security impact is indirect but real. A subscription rule is not an authentication control; Service Bus authorization still depends on RBAC, SAS, managed identity, private endpoints, and namespace network controls. The rule can, however, route sensitive messages to the wrong consumer if message properties or filters are poorly designed. Teams should avoid putting secrets in user properties just to support filtering. Operators should restrict who can change rules, review rule updates like code, and audit access to subscriptions that receive regulated data. If a rule broadens too far, the blast radius becomes data exposure or unauthorized processing, not just a functional bug.
Cost
Subscription rules are not billed as separate resources, but they influence Service Bus operations, storage, and downstream processing cost. A broad rule can increase message copies stored in subscriptions and make consumers process unnecessary events. A narrow but incorrect rule can cause compensating replays, manual repairs, or missed-business-process costs. Complex routing designs may also push teams toward Premium namespaces for isolation and predictable throughput. FinOps review should look at topic fan-out, active and dead-letter message counts, processor compute, and duplicate consumers. The cheapest rule set is usually the clearest one: route only what a consumer owns, then monitor the volume it actually receives.
Reliability
Reliability impact is direct for message delivery semantics. A wrong filter can make a healthy consumer appear broken because the subscription never receives the expected messages. A broad filter can overload a processor with traffic it cannot handle. Deleting the default rule at the wrong time can stop catch-all behavior. Reliable operations use test messages, rule naming standards, backlog metrics, dead-letter monitoring, and release coordination with event schema changes. Idempotent consumers still matter because rule changes can expose new message paths. During incidents, operators should compare published properties with active rule filters before assuming the topic, namespace, or processor is down.
Performance
Performance impact is direct because rules are evaluated as messages enter topic subscriptions. Simple correlation filters are generally easier and more efficient for exact property matches, while SQL filters support richer expressions that can be harder to reason about at scale. Performance problems usually appear as rising backlog, processor lag, or unexpected message fan-out rather than as a visible rule metric. Operators should test filters with realistic message volume, avoid unnecessary catch-all subscriptions, and watch namespace throughput, active messages, lock duration, and consumer concurrency. A clean rule strategy reduces waste by keeping each subscription focused on messages its processor can handle quickly.
Operations
Operators inspect and change subscription rules when onboarding consumers, splitting workloads, debugging missing messages, changing event schemas, or retiring old integrations. They list rules, review filter type, inspect SQL expressions or correlation fields, and verify whether actions mutate matching messages. Good runbooks include the namespace, topic, subscription, rule name, expected message properties, sample test message, and rollback command. Operators also watch active message count, dead-letter count, delivery count, processor logs, and application errors after rule changes. Rule changes should be treated as integration releases because they alter who receives business events. That discipline prevents invisible routing drift during schema changes.
Common mistakes
Leaving the default true filter in place when adding specific rules, causing the subscription to receive every topic message.
Filtering on a property name or casing that the producer never sets, resulting in an empty subscription.
Using a complex SQL filter where a simple correlation filter would be clearer and easier to operate.
Changing event properties in producer code without updating subscription rules and consumer tests.
Deleting or replacing rules during a live incident without exporting the previous configuration for rollback.