Documentation Index

Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt

Use this file to discover all available pages before exploring further.

Tracking data troubleshooting

  • 5 minute(s) read
Prev Next

Overview

This article covers common issues with transaction tracking data in the Business Activity Monitoring (BAM) Pull Model. It addresses query results not converting to transaction instances, missing data, incorrect stage mapping, and data appearing in Azure but not surfacing in BAM.

Business value

Pull Model tracking failures are structurally different from Push Model failures — the source data exists in Azure, but the query, stage mapping, or correlation logic prevents it from appearing as transaction instances in BAM. This article helps you identify where in that chain the failure occurs.

How it works

The Pull Model queries Azure data sources (Application Insights, Log Analytics) on a configurable evaluation schedule and maps the results to transaction instances using a promoted correlation field and stage property mappings. Each stage query can target a different data source, so failures can be isolated to a single stage even when other stages are working correctly. Failures can occur at the query level (no results returned), the mapping level (results returned but not matched to stages), or the correlation level (stages tracked but not assembled into a single instance). Each item in this article identifies the failure point and provides a direct fix.

FAQs

  1. Transaction instances are not appearing in the tracking view after configuring a business process and transaction.
    Cause: The most common causes are: the business process or transaction is not in Active status, the data source has no data matching the configured query, or the query has not yet been evaluated since the business process was activated.
    Fix: Confirm the business process and transaction are Active in Managing business processes and Managing business transactions. Navigate directly to the Azure Application Insights or Log Analytics resource and run the equivalent KQL query manually to confirm it returns data for the expected time window. The evaluation frequency is configurable per business process — wait for at least one full evaluation cycle after activation before drawing conclusions.

  2. The Azure data source contains matching records but BAM shows no transaction instances.
    Cause: The most common cause is a missing or incorrect time field in the query. Every BAM data query must include TimeStamp for Application Insights or TimeGenerated for Log Analytics — omitting this field causes queries to return no results. A second cause is that the stage property mappings do not match the field names or values present in the records.
    Fix: Confirm the query includes the correct time field for the data source type. Then open the transaction in BAM and review the stage configuration in Configuring stages in a transaction. Compare the Property name and Property value fields against the actual field names and values in the Application Insights or Log Analytics records. Correct any mismatch and wait for the next evaluation cycle. See Top tips for data queries for required query fields.

  3. Transaction instances appear but are missing one or more stages.
    Cause: The records for the missing stage either do not exist in the data source for the queried time window, the stage property mapping does not match the records that do exist, or the wrong data source is selected for that stage. Since each stage can target a different data source independently, a misconfigured data source on a single stage will cause only that stage to be missing while others populate correctly.
    Fix: Open the stage configuration in BAM and confirm it is pointing to the correct data source for that stage. In the Azure portal, query that data source directly and confirm records for the missing stage exist within the time window BAM is querying. If the records exist, verify the stage property mapping matches the field names and values in those records exactly. If the records do not exist, the issue is upstream in the source application — the expected telemetry is not being emitted.

  4. Transaction instances are being created but each instance contains only one stage, instead of the full end-to-end sequence.
    Cause: The promoted correlation field used to link records across stages is not producing consistent values. The Pull Model uses a correlation field that you promote from the parent query — BAM joins child query results to the correct transaction instance using this value. If the parent query promotes a field that returns a different value per record rather than per transaction execution (for example, a row ID instead of a run ID), BAM creates a separate single-stage instance for each record instead of assembling them. This issue is especially likely when stages target different data sources, since the correlation value must be consistent across all of them.
    Fix: Review the parent query configuration and confirm the promoted correlation field returns the same value for all records belonging to the same transaction execution across all data sources. For Logic App Consumption, this is typically resource_runId_s. For APIM, the Top tips article uses ItemId. Confirm the value is consistent across all stages by querying each data source directly. See Top tips for data queries for correlation field guidance.

  5. Transaction instances show stale data — the tracking view does not update even though new records are present in Azure.
    Cause: The Pull Model evaluates data sources on a configurable schedule set by the Rules evaluation frequency. If the cycle has not run since the new records arrived, the instances will not yet reflect the latest state. Additionally, if the service principal's client secret has expired, the query cycle fails silently and no new data is retrieved.
    Fix: Wait for the next scheduled query evaluation cycle and refresh the tracking view. If the data still does not update, check the service principal configuration in Business Activity Monitoring > Service principals and confirm the client secret has not expired. See Service principal troubleshooting for steps to resolve an expired secret.

  6. The tracking view returns results but the instance count is lower than the number of records in the Azure data source.
    Cause: BAM deduplicates instances by the promoted correlation field value. Multiple records sharing the same correlation value are assembled into a single instance. If the source application reuses or shares correlation values across distinct transaction executions, BAM merges them rather than creating separate instances.
    Fix: Review the correlation field generation logic in the source application. Each distinct transaction execution must produce a unique correlation value in the promoted field. If values are being reused or shared across executions, update the query or the source telemetry to use a value that is unique per execution — such as a run ID, pipeline run ID, or operation ID.

Related articles