Overview
A business process represents a business workflow modeled in Business Activity Monitoring (BAM) using the Push Model (Custom Logging). It groups a set of related business transactions that together describe an end-to-end operation — such as order fulfillment, invoice processing, or employee onboarding. Each business process belongs to a business process group and is tracked via events your integration solution emits directly to the BAM API.
Each business process contains one or more transactions, and each transaction contains one or more stages. BAM tracks data as it flows through each stage, giving you a complete picture of how your workflow is progressing in real time.
Business value
Business processes let you map your Azure integration workflows to recognizable business concepts. Instead of monitoring individual Azure resources in isolation, you can monitor the entire end-to-end flow as a single unit — reducing mean time to detect failures, improving visibility for non-technical stakeholders, and enabling query- and exception-based alerting aligned to business outcomes.
How it works
A business process is the top-level container in the BAM Push Model data model. Its structure is:
- Business process — the named workflow (e.g. "Logistics booking")
- Transactions — the discrete operations within that workflow (e.g. "Booking Request", "Milestone Status")
- Stages — the checkpoints within each transaction where data is logged
BAM uses the tracking name to identify a business process when correlating incoming data. The friendly name is the display name shown in the Turbo360 interface.
The integration solution supported by BAM is Azure-only, and typically makes use of Azure Integration Services such as Logic Apps, Service Bus queues, Event Grid, and API Management (APIM).
A tracking name is the unique identifier used to correlate runtime data to a business process. It must be unique across the entire BAM product. A friendly name is the label displayed in the Turbo360 tree view and is unique within a business process group.
Example scenario
ShipAnyWhere is a logistics company that manages carrier interactions for each shipment. Their end-to-end shipment flow is modeled as a single business process in Turbo360:
- Friendly name: Logistics
- Tracking name:
shipanywhere-logistics(unique across BAM; used to correlate all incoming events to this process)
The process contains four transactions, each mapped to an Azure Integration Services component:
| Transaction | Azure resource | What it represents |
|---|---|---|
| Booking Request | Logic App (Consumption) | Customer submits a booking; the Logic App receives and validates the payload |
| Booking Confirmation | Service Bus queue | Carrier acknowledgement is queued and consumed by a downstream processor |
| Shipping Instructions | API Management | Carrier-specific routing instructions are dispatched via an APIM policy |
| Milestone Status | Logic App (Consumption) | In-transit and delivery status updates are received and logged |
Each transaction contains stages that act as checkpoints. For the Booking Request transaction, the stages might be:
- Received — logs the raw booking payload when the Logic App trigger fires
- Validated — logs the outcome of schema and business-rule validation
- Submitted to carrier — logs the HTTP response from the carrier API call
BAM correlates data across all four transactions using the tracking name shipanywhere-logistics. When a Milestone Status event arrives, BAM links it to the correct Booking Request instance using a shared correlation property — for example, a booking reference number passed through every stage.
In Turbo360, the entire flow appears as a single business process. You can query any transaction instance by booking reference, inspect which stage last logged data, and configure duration or exception monitoring alerts on any transaction — without switching between individual Azure resource dashboards.