Overview
This article covers common issues with transaction data not appearing as expected in Business Activity Monitoring (BAM). It addresses transaction instances not showing up in the tracking view, missing or incomplete stages, incorrect status values, and data that fails to flow from the source application into BAM.
Business value
Tracking failures are often silent — the source application runs without errors but BAM shows no data. This article helps you pinpoint whether the issue is in data ingestion, stage configuration, or the tracking query, and provides a direct fix for each.
FAQs
-
Transaction instances are not appearing in the tracking view after the source application has run.
Cause: The most common causes are: the business process or transaction is not active in BAM, the source application is sending data to the wrong storage queue, or the BAM polling interval has not yet elapsed since the data was sent.
Fix: First, confirm the business process and transaction are in Active status under Managing business processes and Managing business transactions. Next, verify the storage queue name configured in the transaction matches the queue your source application is writing to. Finally, wait one full polling cycle (typically one minute) and refresh the transaction instances view. -
Transaction instances appear but one or more stages are missing.
Cause: The stage configuration in BAM does not match the property name or value being sent by the source application. BAM matches incoming messages to stages using the stage property mapping — if the property name or expected value differs by even one character (including case), the stage is skipped.
Fix: Open the transaction in BAM and review the stage configuration under Configuring stages in a transaction. Compare the Property name and Property value fields against the actual JSON payload your source application sends. Correct any mismatch and trigger a new test run from the source application. -
Transaction instances show an incorrect or unexpected status (for example, "Failed" when the process succeeded).
Cause: The status BAM assigns to a transaction instance is derived from the stage outcomes. If a stage is configured with an incorrect Failure condition — for example, a property value that legitimately appears in a successful run — BAM will mark the instance as failed.
Fix: Review the failure condition settings for each stage in the transaction configuration. Verify that the property name and value used as the failure indicator are exclusive to genuine failure scenarios and do not appear in successful runs. Update the condition and re-test with a known-good transaction. -
No data reaches BAM from the source Logic App or .NET application, even though the application ran successfully.
Cause: The source application is not correctly calling the BAM ingestion endpoint. Common causes include: the wrong storage connection string in the application configuration, the BAM API key not being passed in the request header, or the .NET library not being initialised with the correct BAM endpoint URL.
Fix: For Logic Apps, confirm the custom connector is configured with the correct storage connection string as described in Logic Apps custom connector. For .NET applications, verify the BAM endpoint URL and API key in the library initialisation call as described in .NET library. Enable diagnostic logging in the source application and confirm that the BAM write call returns HTTP 200. -
Transaction instances appear in BAM but the instance count is lower than the actual number of transactions processed by the source application.
Cause: BAM deduplicates instances using the correlation ID. If the source application sends the same correlation ID for multiple distinct transactions, BAM will merge them into a single instance rather than creating separate records.
Fix: Review the correlation ID generation logic in your source application. Each transaction must use a unique correlation ID. If you are using a static or shared value as the correlation ID (for example, a fixed GUID or a workflow name), replace it with a value that is unique per execution — such as a run ID, message ID, or timestamp-based identifier. See 101 - Sending data to the BAM API for the expected message schema. -
Reprocessed transaction instances do not update their stage status after reprocessing completes.
Cause: Reprocessing sends the transaction through the source workflow again, but BAM only updates the stage status when a new message arrives at the BAM ingestion endpoint. If the reprocessed run does not send data back to BAM, the instance remains in its original state.
Fix: Confirm that the reprocessing path in your source application includes the BAM tracking calls. The reprocessed run must call the BAM ingestion endpoint for each stage, just as the original run did. Review the reprocess configuration in Configuring reprocess for transaction stages to verify the tracking calls are included in the reprocess flow.