Overview
Business Activity Monitoring (BAM) supports a broad range of integration monitoring and operational visibility scenarios. This article describes the most common use cases across teams and roles, and the operational pain point each one addresses.
Business value
- Identify which business processes to instrument first in your operations
- Match each BAM capability to the monitoring challenge your team faces
- Structure your monitoring strategy around concrete operational pain points
How it works
BAM addresses use cases across three operational domains: real-time transaction tracking, alert-driven incident management, and compliance and audit. The use cases below reflect common patterns in Azure integration environments.
Use cases
BAM is used across seven primary use cases. Each one names the teams it suits, the problem it solves, and the key scenarios it covers.
1. End-to-end order and fulfilment tracking
Who it's for: Support teams, operations teams, integration engineers
Organizations that run order management, fulfilment, or supply chain workflows on Azure Logic Apps or Service Bus often lack visibility into the end-to-end journey of a single order. When a failure occurs, support teams must correlate logs across multiple services to find the problem.
Key scenarios:
- Stage-based tracking: track each order as a transaction with named stages: Order received, Payment validated, Inventory reserved, and Dispatch confirmed
- Search by order ID: query by order ID to see the full stage history of a single order
- Property values and exceptions: see the property values and any exceptions recorded for each transaction
- No log correlation: locate a failure without using Azure Monitor or Log Analytics
2. SLA monitoring for business-critical processes
Who it's for: Operations teams, service owners, support managers
Some business processes must complete within a defined time window. For example, a payment transaction must settle within 30 seconds, or a document upload must process within 5 minutes. Manual monitoring does not scale to this kind of requirement.
Key scenarios:
- Expected completion window: define the expected duration of each business process with duration monitoring rules
- Threshold alerts: fire an alert as soon as a transaction exceeds its threshold
- Escalation: escalate to the configured notification channel
- Proactive SLA management: meet SLA commitments before they are breached instead of after
3. Exception-based alerting for integration failures
Who it's for: Integration support teams, on-call engineers, operations teams
Azure integration services generate exception data when workflows fail, but native alerting is often coarse-grained and needs access to Azure Monitor or application-specific log queries.
Key scenarios:
- Stage-level exception capture: capture structured exception data at the transaction stage level
- Threshold-based alert rules: alert when specific exception types occur above a threshold
- Targeted escalation: notify the right team through escalation policies
- No Azure portal access needed: reach recipients who do not have Azure portal access
4. Reprocessing failed transactions without developer involvement
Who it's for: Operations teams, support teams, development teams
In many organizations, replaying a failed integration transaction means raising a ticket to the development team. This adds hours or days to the time it takes to recover and uses developer time on repetitive manual tasks.
Key scenarios:
- Replay from BAM: let authorized operations or support users replay a failed transaction directly from the BAM interface
- Reprocess configuration: define the target endpoint and payload mapping so each replay is repeatable and governed
- No code changes: replay transactions without changing code or raising a ticket
5. Compliance audit trails for regulated industries
Who it's for: Compliance teams, operations teams, audit teams
Industries subject to audit requirements, including financial services, healthcare, and government, need a reliable record of every transaction that passed through a business process, with timestamps, property values, and exception history.
Key scenarios:
- Complete transaction records: keep a record of each transaction instance, including its stage progression, property values, and outcome
- Your own storage: store the records in your Azure storage account
- Queryable audit trail: give operations and compliance teams a structured trail they can query instead of relying on temporary log data
6. Monitoring heterogeneous integration landscapes
Who it's for: Integration architects, platform teams, operations teams
Environments that mix Logic Apps, Azure Functions, Service Bus, API Management, and custom .NET services typically lack a single monitoring surface. Each service has its own telemetry model, and correlating events across services needs custom tooling or expensive BI infrastructure.
Key scenarios:
- One monitoring model: use business processes, transactions, and stages across all supported Azure services
- Cross-service transactions: track a transaction that passes through a Logic App, a Function, and a Service Bus queue as one transaction
- Consistent interface: monitor every service the same way, without custom correlation tooling
7. Operational dashboards without BI tooling
Who it's for: Business operations teams, support teams
Business operations teams often need a live view of transaction throughput, failure rates, and processing times, but lack the skills or access to build Power BI dashboards or Log Analytics queries.
Key scenarios:
- Live operational view: monitor transaction throughput, failure rates, and processing times in the Turbo360 portal
- Failure drill-down: drill into failed transactions
- Trend tracking: track trends over time
- No BI tooling: get all of this without BI or query tooling