Configuring end-to-end tracking

Prev Next

Overview

This tutorial guides you through configuring end-to-end tracking in Business Activity Monitoring (BAM) using the Custom Logging (Push Model) deployment type. Starting from a deployed BAM environment, you will configure a business process, define transactions with multiple stages, instrument a Logic App to send tracking events, and use the transaction instances view to confirm that a complete workflow run is tracked from first event to final stage.

Business value

End-to-end tracking gives your operations team visibility into every step of an integration workflow — not just whether it completed, but which stage it failed at, how long each stage took, and what the message payload looked like at each checkpoint. This visibility turns reactive incident response into targeted diagnosis, cutting mean time to resolution for integration failures.

Prerequisites

Before starting this tutorial, confirm the following:

Required permissions

Action Minimum role
Configure business processes and transactions Contributor
Configure stages Contributor
View and query transaction instances Reader
Reprocess failed instances Contributor

Dependencies

  • BAM Function App must be running and reachable from the Logic App.
  • The Logic Apps custom connector must be added as a connection in the Logic App before checkpoint actions are available in the designer.

How it works

End-to-end tracking in BAM works through a chain of checkpoint events. Each checkpoint action in your Logic App sends a structured event to the BAM API containing the business process tracking name, transaction tracking name, stage name, and a correlation ID. The BAM runtime groups all events that share the same correlation ID into a single transaction instance and advances its status as each stage event arrives.

The transaction instance view shows the result: a single row per workflow run, with each stage column populated with a status (completed, failed, or pending), elapsed time, and — if message archival is enabled — the archived payload for that stage.

For multi-step workflows that include branching, exception handling, or parallel paths, each branch can independently send checkpoint events to the same transaction instance using the same correlation ID. BAM merges them into a unified view.

Steps

This tutorial covers four tasks: designing the stage map, configuring stages in BAM, instrumenting the Logic App with checkpoint actions, and verifying the full tracking chain. Navigate to Business Activity Monitoring in the Turbo360 tree view to get started.

Step 1: Design your stage map

Before configuring anything in BAM, define the stages your workflow should track. A stage map lists each logical checkpoint in the order the workflow processes them.

For this tutorial, the example workflow is an order processing Logic App with the following stages:

Stage Description
Order Received Triggered when the Logic App starts
Payment Validated After a payment check action completes
Inventory Reserved After a stock check action completes
Order Dispatched Final stage — order is sent to fulfillment

Write down the exact stage names you will use. Stage names in BAM and in the Logic App checkpoint actions must match exactly — they are case-sensitive.

Step 2: Configure stages in BAM

Add each stage from your stage map to the transaction in BAM.

  1. In the tree view, expand Business Activity Monitoring > your business process group > your business process > your transaction.
  2. Click the Context menu ( ⋮ ) next to the transaction and select New Stage.
  3. Enter the Stage name — for example, Order Received.
  4. Leave the stage type as the default for standard intermediate stages.
  5. Click Save.
  6. Repeat for Payment Validated and Inventory Reserved.
  7. Add the final stage: enter Order Dispatched as the stage name, then enable the Mark as final stage option.
  8. Click Save.

:::(Info)(Note:)
Marking a stage as final tells BAM to automatically close the transaction instance and set its status to Completed when that checkpoint event is received. A transaction with no final stage will remain In Progress indefinitely.
:::

Step 3: Instrument the Logic App

Add a BAM checkpoint action at each stage of the Logic App workflow.

  1. Open the Logic App in the Azure portal or in VS Code.
  2. At the point in the workflow where the first stage occurs (order trigger), add a BAM Checkpoint action from the Logic Apps custom connector.
  3. Configure the checkpoint action with the following values:
    • Business process tracking name — the tracking name of your business process (for example, order-fulfillment)
    • Transaction tracking name — the tracking name of your transaction (for example, process-order)
    • Stage nameOrder Received
    • Correlation ID — a unique value that identifies this workflow run. Use an expression to extract the order ID from the trigger payload (for example, triggerBody()?['orderId']).
  4. Add a second checkpoint action after the payment check action:
    • Same business process and transaction tracking names
    • Stage namePayment Validated
    • Same correlation ID expression
  5. Add a third checkpoint after the inventory check:
    • Stage nameInventory Reserved
    • Same correlation ID expression
  6. Add the final checkpoint after the fulfillment action:
    • Stage nameOrder Dispatched
    • Same correlation ID expression
  7. Save and publish the Logic App.
Note:

The correlation ID must be the same value across all checkpoint actions for the same workflow run. If any checkpoint uses a different value, BAM creates a separate transaction instance for that event rather than appending it to the existing one.

Step 4: Trigger and verify

Run the Logic App and confirm that all stages appear in the transaction instances view.

  1. Trigger the Logic App by sending a test request or manually running it from the Azure portal.
  2. In Turbo360, navigate to Business Activity Monitoring > your business process > your transaction in the tree view.
  3. Click the Context menu ( ⋮ ) next to the transaction and select View Instances.
  4. Locate the instance that corresponds to your test run using the correlation ID or the timestamp.
  5. Confirm that all four stages — Order Received, Payment Validated, Inventory Reserved, Order Dispatched — are populated with a Completed status.
  6. Click the instance row to expand it and inspect per-stage details: elapsed time, event timestamp, and — if message archival is enabled — the archived payload.

If all four stages show as completed, end-to-end tracking is working correctly for this workflow.

Troubleshooting

  1. One or more stages show as pending after the Logic App run completes
    Cause: The checkpoint action for that stage did not execute, or the stage name does not exactly match the name configured in BAM.
    Fix: Open the Logic App run history and confirm the checkpoint action for that stage ran successfully. Verify the stage name in the action matches the BAM configuration exactly (case-sensitive).

  2. Two separate transaction instances appear for the same workflow run
    Cause: The correlation ID value differs between two or more checkpoint actions in the same run.
    Fix: Review each checkpoint action's correlation ID expression and confirm they all resolve to the same value for the same trigger input.

  3. Transaction instance status is stuck on In Progress after the final stage fires
    Cause: The final stage in BAM is not marked with the Mark as final stage option, or the final checkpoint action's stage name does not match the configured final stage name.
    Fix: In BAM, open the final stage configuration and confirm the Mark as final stage option is enabled. Confirm the stage name in the Logic App checkpoint matches exactly.

  4. No transaction instances appear at all after triggering the Logic App
    Cause: The BAM Function App may be stopped or the checkpoint action may be connecting to the wrong BAM endpoint.
    Fix: Confirm the BAM Function App is running in the Azure portal. In the Logic App, inspect the BAM custom connector connection and verify it points to the correct BAM API endpoint.

  5. Elapsed time for a stage is unexpectedly high
    Cause: A downstream action before the checkpoint is taking longer than expected, or there is a retry loop delaying the checkpoint event.
    Fix: Review the Logic App run history for that action's execution time. Check for retry policies on any action upstream of the checkpoint.

Related articles