Overview
Business Activity Monitoring (BAM) supports two ways to get tracking data into the system: the Push Model and the Pull Model. Both produce transaction instances you can monitor and alert on, but they work very differently and suit very different situations. The choice you make at the start determines your infrastructure requirements, how much you can control what gets tracked, and which BAM features are available to you.
Business value
Choosing the wrong model creates a mismatch between what your integrations can provide and what BAM can do with that data. Getting this right upfront means your team builds once — not twice.
How it works
Push Model (Custom Logging) — your integration actively sends tracking events to the BAM API at each stage of a business process. BAM receives the event, matches it to a configured transaction, and creates or updates the instance in real time. You instrument your solution to emit events; BAM records exactly what you tell it.
Pull Model (Data Queries) — BAM queries an existing data source (Application Insights, Log Analytics, or Azure Data Explorer) on a schedule and constructs transaction instances from the results. Your integration doesn't need to change at all — BAM reads telemetry it's already producing.
Decision guide
Start here: can your integration be modified to emit events?
If yes — use the Push Model unless a specific constraint rules it out.
If no — use the Pull Model as the pragmatic alternative.
Then check these factors:
Use the Push Model when:
- You are building a new integration from scratch
- You need to reprocess failed transactions from the BAM portal
- You need duration monitoring or exception monitoring alerts
- You need message archival at specific stages for audit or support purposes
- You need to track custom business properties that only exist inside the integration logic, not in Azure telemetry
- Real-time transaction visibility is a hard requirement
Supported technologies: Logic Apps (Standard and Consumption), Azure Functions, API Management, Power Automate, Data Factory (via Web Activity), custom .NET code, PowerShell, MuleSoft, Boomi, Frends, and any HTTP-capable platform.
Use the Pull Model when:
- The integration is already emitting structured telemetry to App Insights, Log Analytics, or ADX, and that telemetry contains the correlation IDs and status data you need
- The integration is owned by a team that cannot or will not add BAM API calls
- You need to add tracking visibility to a live integration without a deployment window
- The integration is a data pipeline (Data Factory, Synapse) where telemetry is the primary observability mechanism
- You're monitoring a third-party system you don't control
Supported data sources by technology:
| Technology | Data source |
|---|---|
| Logic App Standard | Application Insights, ADX (Business Process Tracking) |
| Logic App Consumption | Log Analytics |
| Azure Functions | Application Insights |
| API Management | Application Insights |
| Data Factory | Log Analytics |
| Custom code | Application Insights, custom ADX via Event Hub |
Feature comparison
| Feature | Push Model | Pull Model |
|---|---|---|
| Real-time data | ✓ Events arrive as they occur | Near real-time — after next scheduled query |
| Integration changes required | Yes — instrument your solution | No — reads existing telemetry |
| Infrastructure | BAM environment (Storage Account, Azure Functions) | Service principal with read access to data source |
| Stage configuration | Full — per-stage properties, conditional stages | Limited — defined by query results |
| Reprocessing | ✓ Supported | ✗ Not available |
| Message archival | ✓ Supported | ✗ Not available |
| Exception monitoring | ✓ Supported | ✗ Not available |
| Duration monitoring | ✓ Supported | ✗ Not available |
| Query monitoring | ✓ Supported | ✓ Supported |
| Control over tracked data | High — you define exactly what is captured | Medium — limited to what telemetry already records |
When to use both
A mixed integration estate is common. Use the Pull Model as a bridge while you incrementally migrate existing integrations to the Push Model. Once an integration is re-instrumented for Push, retire the corresponding Pull Model transaction to avoid duplicate instances.
Critical rule: Never configure the same transaction to use both models. Mixing models for the same transaction produces duplicate instances and makes query results unreliable. If your business process spans Push and Pull integrations, model each as a separate transaction and accept that Pull Model transactions will have a reduced feature set.
Latency note
Push Model events typically arrive within seconds. Pull Model data latency depends on the underlying source — Application Insights can have an ingestion delay of 2–5 minutes under normal conditions, longer during high-load periods. If your monitoring rules need to detect failures within a tight window, the Pull Model may not provide sufficient freshness.
Example scenario
A platform team is adding BAM coverage to a mixed integration estate:
- A new order fulfilment Logic App is being built from scratch → Push Model. The team instruments the Logic App with BAM API calls at each stage, enabling duration monitoring and reprocessing.
- An existing inventory sync Data Factory pipeline already writes structured logs to Application Insights → Pull Model. The team configures a Data Queries transaction reading from App Insights using the existing correlation ID. No pipeline changes are required.
- A third-party ERP integration emits events to an APIM endpoint the platform team controls → Push Model via APIM proxy. The team instruments the APIM policy with a BAM API call at entry and exit points, without touching the third-party system.
The two Push Model transactions have full monitoring and reprocessing capability. The Pull Model transaction provides visibility into the Data Factory pipeline but does not support reprocessing or exception monitoring.