Deployment model selection

Overview

Business Activity Monitoring (BAM) supports two deployment models: Push Model (Custom Logging) and Pull Model (Data Queries). Each model determines how your integration sends tracking data to BAM, which BAM features are available, and what infrastructure is required. Choosing the right model — or the right combination — is one of the most consequential decisions in a BAM deployment.

This article describes the characteristics of each model, the criteria for selecting between them, and the patterns for combining them when your environment contains both types of integration.

Business value

Choosing the wrong deployment model creates a mismatch between what your integrations can provide and what BAM can do with that data. Selecting the right model from the start avoids costly rework when features such as reprocessing, stage configuration, or data-source-specific queries turn out to be unavailable in the chosen model.

How it works

The two models differ in how tracking data reaches BAM:

• Push Model (Custom Logging) — your integration actively sends events to the BAM API at each stage. The BAM Tracker function app receives the events, places them on a Service Bus queue, and the BAM processor writes them to the BAM datastore. Your integration is the source of truth; BAM records what the integration tells it.

• Pull Model (Data Queries) — BAM queries an existing data source (such as Azure Application Insights, Azure Monitor Logs, or a custom data store) to retrieve tracking data on demand. Your integration does not send events to BAM; BAM reads from the data source directly using a configured query.

Key practices

1. Choose the Push Model when your integration can be instrumented

If you are building a new integration, or modifying an existing one, prefer the Push Model. It provides the full BAM feature set — including reprocessing, exception monitoring, duration monitoring, message archival, and per-stage property extraction — none of which are available in the Pull Model.

Situations that favour the Push Model:

• You are building a new Logic App, Azure Function, or APIM-based integration.
• You need to reprocess failed transaction instances from the BAM portal.
• You need duration or exception monitoring on the operation.
• You need to archive message bodies at specific stages for audit or support purposes.
• You need to track custom properties that are only available inside the integration (not in App Insights telemetry).

2. Choose the Pull Model when instrumentation is impractical

The Pull Model is the right choice when you cannot or should not modify the integration to send BAM events — for example, when the integration is a third-party system, a locked-down legacy workflow, or a read-only data pipeline.

Situations that favour the Pull Model:

• The integration already emits structured telemetry to Application Insights or Azure Monitor, and that telemetry contains the correlation identifiers and status information 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 an existing integration without a deployment window.
• The integration is a data pipeline (Data Factory, Synapse) where telemetry is the primary observability mechanism.

The Pull Model gives you query-based visibility into existing data — it does not give you control over what data is captured or the ability to act on instances from the BAM portal.

3. Use the Pull Model as a bridge while migrating to the Push Model

If you are adding BAM to an existing estate of integrations, use the Pull Model to establish visibility quickly while you incrementally migrate integrations to the Push Model. This avoids a big-bang instrumentation project and gives you some BAM coverage during the transition period.

Once an integration has been re-instrumented to use the Push Model, retire the corresponding Pull Model transaction to avoid duplicate instances appearing in the BAM portal.

4. Do not mix Push and Pull for the same transaction

A given transaction in BAM should be configured for either the Push Model or the Pull Model — not both. Mixing models for the same transaction produces duplicate instances (one from the Push API call, one from the Pull query) and makes query results unreliable.

If your business process spans integrations of both types, model each model-specific segment as a separate transaction, and accept that the Pull Model transactions will have a reduced feature set.

5. Account for latency differences between models

Push Model events arrive in near-real-time — typically within seconds of the stage being reached. Pull Model data availability depends on the latency of the underlying data source. Application Insights, for example, can have an ingestion delay of two to five minutes under normal conditions, and longer during high-load periods.

If your monitoring rules depend on detecting failures within a tight window, the Pull Model may not provide sufficient freshness. Duration monitoring and exception monitoring are not available in the Pull Model; query monitoring is available but is subject to source latency.

6. Review the available samples before building a new Pull Model integration

The BAM Pull Model Samples section contains worked examples for the most common data source configurations, including Logic App Consumption, Data Factory, API Management, Azure Functions, and Application Insights. Review the sample closest to your integration before designing your query configuration — the samples include the correct query syntax, correlation property mapping, and known limitations for each source.

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 from the BAM portal.
• An existing inventory sync Data Factory pipeline already writes structured logs to Application Insights → Pull Model. The team configures a Data Queries transaction that reads from App Insights using the existing correlation ID in the telemetry. No pipeline changes are required.
• A third-party ERP integration emits events to an APIM endpoint that the platform team controls → Push Model via APIM proxy. The team instruments the APIM policy with a BAM API call at the 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.

Related articles

• Understanding the Push Model
• Understanding the Pull Model
• Environment setup
• 101 - Sending data to the BAM API
• Tracking strategy
• Deployment details