Overview
Business Applications and Business Activity Monitoring (BAM) are both Turbo360 modules that help you monitor Azure workloads — and at first glance, their overlap can be confusing. Both surface health data, both fire alerts, and both are described using words like "monitoring" and "visibility." But they answer fundamentally different questions, and using the wrong one for your scenario will leave you with gaps you didn't expect.
Business value
Understanding the distinction upfront prevents you from configuring the wrong module and discovering months later that it can't answer the questions your team actually needs answered.
The core distinction
Business Applications asks: "Are my Azure resources healthy?"
It monitors the operational state of Azure infrastructure — is a Logic App failing runs? Is a Service Bus queue backing up? Is an Azure Function timing out? It groups resources into logical units so you can monitor the health of an entire solution from one place, rather than resource by resource in the Azure portal.
BAM asks: "Did this specific business transaction complete successfully?"
It tracks the lifecycle of individual business processes — did order #4821 flow from received to validated to fulfilled? Did the payment for customer X get processed? Where exactly did invoice batch #1042 stall? BAM gives business users and support teams the ability to answer these questions without developer involvement.
Decision guide
Use Business Applications when your concern is infrastructure health:
- You want to know whether the Azure resources supporting a solution are up, healthy, and performing within thresholds
- You need to monitor availability, resource state, metric thresholds (CPU, memory, queue depth), API endpoint health, or activity log conditions
- You want operational health visibility across resources that span multiple subscriptions and resource groups
- You need automated operations like starting, stopping, or restarting resources in response to conditions
- The audience for the monitoring output is your operations or infrastructure team
Use BAM when your concern is business process outcomes:
- You want to know whether specific business transactions completed — and where they failed if they didn't
- You need to track a single message or record as it moves through multiple Azure services
- You need to give support teams the ability to query "where is order X right now?" without escalating to a developer
- You need to reprocess a failed transaction without a developer writing custom retry logic
- You need an audit trail of every instance of a business process, with its tracked properties and stage progression
- The audience is support teams, operations teams, or business stakeholders — not just infrastructure engineers
Comparison
| Question | Business Applications | BAM |
|---|---|---|
| Are my Azure resources healthy? | ✓ | ✗ |
| Did transaction #4821 complete? | ✗ | ✓ |
| Why is my Logic App failing runs? | ✓ (rule-based alerts on run failures) | ✗ |
| Where did order #4821 stall? | ✗ | ✓ |
| Is my Service Bus queue backing up? | ✓ (metric threshold monitoring) | ✗ |
| Did the payment batch for today complete? | ✗ | ✓ |
| Alert me when a resource goes unavailable | ✓ | ✗ |
| Alert me when a transaction takes too long | ✗ | ✓ (duration monitoring) |
| Alert me when a transaction fails | ✗ | ✓ (exception monitoring) |
| Reprocess a failed message | ✗ | ✓ (Push Model only) |
| Monitor resources across subscriptions | ✓ | ✗ |
| Track a message across multiple services | ✗ | ✓ |
Why teams use both
Most enterprise Azure environments need both modules, because infrastructure health and business process outcomes are separate concerns.
A Logic App can show zero run failures in Business Applications while individual business transactions tracked in BAM are silently timing out — because the Logic App ran successfully but the downstream service it called returned an unexpected response that your business process logic treats as a stall. Conversely, BAM can show a transaction instance stuck at the "validated" stage while Business Applications tells you why: the downstream Service Bus queue is healthy but the processing Function App is throttled.
The two modules complement each other — Business Applications gives you the infrastructure signal, BAM gives you the business outcome. Running both means you can correlate them.
Example scenario
An operations team supports an order processing system built on Logic Apps, Service Bus, and Azure Functions.
They use Business Applications to monitor the health of those Azure resources as a group — they get alerted if the Logic App starts failing runs, if the Service Bus queue depth exceeds a threshold, or if the Function App becomes unavailable. They can start and stop resources from within Turbo360 without going to the Azure portal.
They use BAM to track individual purchase orders through the end-to-end process — from order received, through payment validated, to fulfilment dispatched. When a customer calls to ask why their order hasn't shipped, a support agent can search by order ID in BAM and see exactly which stage the order reached and what properties were captured at each step. If the order failed at the payment stage, the agent can reprocess it directly from the BAM interface.
Neither module alone gives the full picture. Together, they cover both the infrastructure layer and the business outcome layer.