Tracking strategy

Overview

A tracking strategy defines which operations you instrument with Business Activity Monitoring (BAM), how you propagate correlation identifiers through your Azure integrations, what data you capture at each stage, and how you configure monitoring to detect failures automatically. This article describes the principles and patterns that produce a tracking strategy that is operationally useful, maintainable, and scalable.

Business value

Without a deliberate tracking strategy, BAM deployments tend to produce one of two failure modes: over-instrumentation (tracking everything, producing noise and storage pressure) or under-instrumentation (tracking too little to be useful during incidents). A defined strategy avoids both and ensures that BAM delivers the visibility it was deployed to provide.

How it works

Tracking in BAM is additive — you choose which operations to instrument, which stages to log within each operation, and which properties to extract from the event payload at each stage. The tracking strategy is the set of decisions that governs these choices consistently across all teams and workloads that use BAM.

A good strategy answers four questions:

1. What operations should be tracked? — which business workflows have enough operational significance to warrant end-to-end visibility.
2. How will correlation identifiers be propagated? — how the Transaction Instance ID flows from the trigger through every stage in the operation.
3. What properties should be captured? — which values have query, alert, or audit significance.
4. What monitoring rules should be configured? — which operations need duration thresholds, exception detection, or query-based alerting.

Key practices

1. Instrument at the business boundary, not the resource boundary

Track operations that cross system boundaries or represent a business commitment — not every action inside a single service. A Logic App that calls three Azure Functions internally should be tracked as one transaction with meaningful stages (for example, Received, Validated, Dispatched), not as a separate event per Function invocation.

Operations worth tracking share at least one of these characteristics:

• A failure or delay would be visible to an end customer or business stakeholder.
• The operation is subject to a contractual or internal SLA.
• A failed operation can be reprocessed or escalated by an operations team.
• The outcome of the operation needs to be audited.

2. Establish a correlation ID strategy before instrumentation begins

The Transaction Instance ID is the single most important design decision in your tracking strategy. It must be chosen and documented before any instrumentation is built, because changing it later requires updating every integration that sends BAM events.

Good correlation ID sources, in order of preference:

1. Business keys — order numbers, invoice IDs, booking references, case numbers. These are meaningful to stakeholders and stable across reprocessing.
2. Message correlation IDs — IDs generated at the message entry point (API gateway, Logic App trigger, Service Bus session ID) and propagated through HTTP headers or message properties. These are stable within a single processing attempt.
3. Synthetic IDs — GUIDs generated at the first stage and propagated explicitly. Use these only when no natural business key or stable correlation property exists.

Avoid using IDs that change on reprocessing (Azure Logic App run IDs, Service Bus message IDs without session correlation). If an instance is reprocessed, a new Azure-generated ID is created — BAM will create a new instance instead of updating the original.

3. Propagate the correlation ID explicitly through every integration hop

The correlation ID does not propagate automatically through Azure Integration Services. You must carry it forward explicitly:

• Logic Apps — pass the correlation ID in a custom HTTP header (e.g. x-correlation-id) between Logic App calls and APIM policies. Extract it at each BAM stage using an HTTP header property source.
• Service Bus — store the correlation ID in a user property on the Service Bus message. Downstream consumers that receive the message must read and forward the same property.
• Event Grid — include the correlation ID in the event data payload. Subscribers must extract and forward it.
• Azure Functions — pass the correlation ID in the function invocation context (HTTP header or queue message property) and include it in any outbound calls.

Define the header name and property key as a shared convention across all teams contributing integrations to the same business process. Inconsistency in naming causes correlation failures that are difficult to diagnose.

4. Track the minimum set of properties needed for operations

For each stage, identify the properties that a support analyst would need when investigating a failed or delayed instance. The practical test: imagine the support call — "we have a failed payment for customer X, can you check the status?" — and identify what you would need to answer it quickly.

A useful minimum set for most operations:

Avoid tracking large text values (message bodies, XML payloads) as tracked properties. Use message archival for payload capture. Large property values slow down queries and increase storage costs without proportional operational benefit.

5. Configure monitoring rules as part of go-live, not as an afterthought

Duration monitoring and exception monitoring rules should be configured and tested before an integration goes live in production — not added reactively after the first missed SLA or undetected failure.

For each transaction with a measurable SLA or expected completion window, configure a duration monitoring rule with:

• A threshold based on observed p95 completion time in non-production environments, plus a safety margin.
• An escalation policy that routes alerts to the team responsible for that integration within the contracted response time.

For transactions with known failure modes (for example, carrier API unavailable, schema validation failure), configure exception monitoring rules that fire when the failure stage is reached without a subsequent success stage within the expected window.

Query monitoring is most useful for operations where the absence of data is itself a signal — for example, a batch import transaction that should produce at least one instance every weekday. Configure a query monitoring rule that alerts when the expected instance count falls to zero during the expected processing window.

6. Organize business processes to reflect organizational or domain boundaries

Group transactions into business processes by the domain or team that owns the end-to-end flow — not by Azure resource type or deployment environment. A single business process should represent a workflow that one team is responsible for monitoring and operating.

When multiple teams share a BAM environment, use business process groups to separate their processes in the tree view. Assign BAM roles so that each team has manage access to their own processes and read access to others, preventing accidental misconfiguration across domain boundaries.

7. Document your tracking model as part of your integration design

Your tracking model — the list of business processes, transactions, stages, tracked properties, and monitoring rules — is part of your integration design, not just a configuration artefact. Treat it as such:

• Document it alongside your integration design documentation.
• Review it during integration design reviews before development begins.
• Update it when the integration is changed or extended.
• Include BAM monitoring verification in your go-live checklist.

Example scenario

A logistics integration team deploys BAM for a shipment management workflow. Before writing any code, they document the following tracking model:

• Business process: Shipment Management (owned by the Logistics Integration team)
• Correlation ID: shipmentReference — a business key generated at order creation and passed in the x-correlation-id HTTP header through all Logic Apps and APIM policies
• Transactions and stages:

• Monitoring rules:
  • Duration monitoring on Booking Request: alert if not completed within 5 minutes.
  • Exception monitoring on Booking Request: alert if Validated stage is reached with a validationResult of REJECTED.
  • Query monitoring on Booking Confirmation: alert if no instances are received between 08:00 and 18:00 on weekdays.

The team configures all rules before the first production deployment and verifies them with a test shipment before go-live.

Related articles

• Transaction design
• Business processes
• Configuring stages in a transaction
• Duration monitoring
• Exception monitoring
• Query monitoring
• Deployment model selection