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.

Data queries and tracking FAQs

  • 4 minute(s) read
Prev Next

Overview

This article answers common questions about configuring data queries and tracking transaction instances in the Business Activity Monitoring (BAM) Pull Model. It covers query configuration, correlation fields, required time fields, multi-source transactions, and how BAM assembles transaction instances from query results.

Business value

Data query configuration is the most technically involved part of Pull Model setup. This FAQ collection addresses the questions that come up most frequently when teams first map their Azure telemetry to BAM transactions.

How it works

This article covers questions across three areas: how queries are configured and executed, how correlation fields work, and how transaction instances are assembled and viewed. Questions progress from initial query setup through to interpreting tracking results.

FAQs

  1. What is a data query in the Pull Model context?
    A data query is the configuration that tells BAM what to retrieve from a data source for a specific transaction or stage. Each transaction in the Pull Model has a parent query that identifies individual transaction instances, and a set of child queries that map to transaction stages. Each stage query can target a different data source — for example, one stage can query Application Insights while another queries Log Analytics — allowing you to track transactions that span multiple Azure services. BAM uses the promoted correlation field from the parent query to join all stage results into the correct instance. See BAM data queries overview for an introduction.

  2. How does BAM know which query results belong to the same transaction instance?
    BAM uses a promoted correlation field from the parent query to group results from different stages into a single transaction instance. When you configure the parent query, you designate one of its output columns as the correlation field — BAM uses the value in that column to join all child query results that share the same value into one instance. The column you promote depends on your data source and technology: for Logic App Consumption, resource_runId_s is typical; for APIM, ItemId is commonly used. Choose a column that returns a unique, consistent value per transaction execution. See Top tips for data queries for correlation field guidance.

  3. Can I use different data sources for different stages in the same transaction?
    Yes. Each stage query is configured independently and can target a different data source. For example, a transaction could have one stage querying Application Insights for a Logic App step and another stage querying Log Analytics for a Data Factory pipeline run. This allows BAM to track end-to-end transactions that flow across multiple Azure services logging to different observability stores. Make sure the promoted correlation field value is consistent across all data sources — the same value must appear in every stage's query results for BAM to assemble them into one instance.

  4. What time field do I need to include in my queries?
    Every BAM data query must include a time field so BAM can apply time filters when retrieving records. The required field depends on the data source: use TimeStamp for Application Insights and TimeGenerated for Log Analytics. Omitting the time field causes queries to return no results, regardless of what data exists in the source. See Top tips for data queries for the full list of required query fields.

  5. What query language does BAM use for Application Insights and Log Analytics queries?
    Both Application Insights and Log Analytics use Kusto Query Language (KQL). When configuring a transaction query, you write KQL that returns the records you want BAM to track. Custom query monitoring rules also use KQL — they must return a scalar (single numeric) value for threshold evaluation. See BAM data queries overview and the code samples in Developer Platform > Code Samples > BAM for query examples by technology and data source.

  6. How do I view the transaction instances that BAM has assembled from my query results?
    Navigate to Business Activity Monitoring > your Business Process group > the relevant business process, then open the Transactions view. Use the filter controls to scope by date range, status, or other available properties. Select any instance to open the detail view, which shows the stages that have been populated and the data returned for each. See Querying transaction instances and View transaction details.

  7. How frequently does BAM run queries against the data sources?
    The evaluation frequency is configurable per business process using the Rules evaluation frequency setting in the query monitoring configuration. For example, you can set it to run every 15 minutes. This interval controls both transaction tracking queries and query monitoring rule evaluation. There is no fixed platform-level polling interval — the frequency you configure determines how quickly new data appears in the tracking view.

  8. Can I filter the data query results to only capture specific records, or does BAM retrieve everything from the data source?
    Yes. The KQL query you write for each stage or transaction determines exactly which records BAM retrieves. You can filter by time range, by custom properties, by operation name, or by any other field available in the data source. Writing focused queries that return only the records relevant to the stage keeps query execution efficient and reduces noise in the transaction instances view. See the code samples in Developer Platform > Code Samples > BAM for query examples scoped to specific Logic App and Data Factory patterns.

  9. Does BAM support status indicators on transaction instances?
    Yes. You can map a column from your query to the transaction or stage status field in BAM. BAM uses this value to display a colored status indicator in the portal. Use a KQL case statement to derive a status column from your existing data when multiple source fields contribute to the final status value. See Top tips for data queries for a status mapping example.

Related articles