Logic App Standard workflow support

Overview

Logic App Standard workflows do not support custom connectors, which is how Business Activity Monitoring (BAM) tracking is typically instrumented in Logic App Consumption workflows. This article explains how to instrument BAM tracking in a Logic App Standard workflow using HTTP actions and the BAM API.

Business value

Logic App Standard workflows are increasingly used for enterprise integration scenarios that require isolated, dedicated compute. Supporting BAM tracking in Standard workflows ensures you can apply the same end-to-end transaction visibility to Standard-based integrations as you do to Consumption-based ones, without changing your BAM configuration or business process design.

How it works

Logic App Consumption workflow

In the Consumption workflow, you can use the Logic Apps custom connector to instrument BAM tracking. Create the connector by providing the BAM swagger file and an API connection. The custom connector exposes three actions:

Start Transaction: begins tracking a new transaction instance.
Checkpoint: records a stage completion for an existing transaction instance.
Checkpoint with Correlation: records a stage completion and associates correlation properties.

Logic App Standard workflow

Logic App Standard does not support custom connectors. Instead, use Azure HTTP actions with the BAM exposed API URLs to instrument the same tracking calls.

Retrieve the BAM API URLs from Business Activity Monitoring > Actions > BAM Connection details.

The overall Standard workflow structure mirrors the Consumption approach: an HTTP action calls the StartTransaction endpoint, subsequent HTTP actions call the Checkpoint endpoint for each stage, and conditions branch the flow based on tracked property values.

Steps

Use the following steps to configure HTTP actions in a Logic App Standard workflow for BAM tracking. Open your Logic App Standard workflow in the Azure portal to get started.

Configure the StartTransaction HTTP action

The StartTransaction HTTP action begins a new transaction instance in BAM and returns the TransactionInstanceId used by all subsequent Checkpoint calls.

Add an HTTP action to your workflow at the point where the transaction should begin.
Set the Method to POST and the URI to the BAM StartTransaction API URL from BAM Connection details.
Add the following required headers:

Header	Required
`BAM-BusinessProcess`	Yes
`BAM-Transaction`	Yes
`BAM-Stage`	Yes
`BAM-StageStatus`	No
`BAM-BatchId`	No

Set the Body using the following payload format:

{
  "messageBody": {},
  "messageHeader": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  }
}

Configure conditions

Add a Condition action after StartTransaction to branch the workflow based on a tracked property value.

Input for Condition: trigger().outputs.body.messageBody.Number

Number is the user-defined property name whose value the condition evaluates.

Input for Transaction Instance Id: body('StartTransaction')['TransactionInstanceId']

StartTransaction is the name of the HTTP action that called the StartTransaction URL.

Configure Checkpoint HTTP actions

Add a Checkpoint HTTP action for each stage in the workflow. Each Checkpoint call advances the transaction instance to the next stage in BAM.

Add an HTTP action after each stage logic completes.
Set the Method to POST and the URI to the BAM Checkpoint API URL.
Add the following required headers:

Header	Required
`BAM-Stage`	Yes
`BAM-StageStatus`	Yes
`BAM-TransactionInstanceId`	Yes
`BAM-IsTransactionComplete`	No

Set the Body using the Checkpoint payload format:

{
  "messageBody": {},
  "messageHeader": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  }
}

For CheckpointWithCorrelation, use the following payload format instead:

{
  "property": [
    {
      "name": "string",
      "value": "string"
    }
  ],
  "messageBody": {},
  "messageHeader": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  }
}

Example scenario

An order management integration built on Logic App Standard sends tracking events directly to the BAM API. The workflow calls StartTransaction when an order arrives, records a Checkpoint after each processing stage (validation, fulfillment, and dispatch), and sets BAM-IsTransactionComplete: true on the final Checkpoint. The complete transaction flow is visible in the BAM tracking page, with each stage showing its status and any exception details.

Limitations

Logic App Standard workflows do not support the Logic Apps custom connector. HTTP actions with the BAM API are the only supported instrumentation method for Standard workflows.
The BAM-TransactionInstanceId header on Checkpoint calls must be populated from the StartTransaction response. If the StartTransaction action fails, subsequent Checkpoint calls will not be associated with a transaction instance.

Troubleshooting

Checkpoint call returns an error or no transaction instance is created
Cause: The BAM-TransactionInstanceId header is missing or populated with an incorrect expression.
Fix: Verify the expression used to extract TransactionInstanceId from the StartTransaction response: body('StartTransaction')['TransactionInstanceId']. Ensure the HTTP action name in the expression matches the actual action name in your workflow.
Transaction is not appearing in the BAM tracking page
Cause: The BAM-BusinessProcess or BAM-Transaction headers do not match the names configured in BAM.
Fix: Cross-check the header values against the business process and transaction names in Business Activity Monitoring > Business Processes. Values are case-sensitive.
StartTransaction HTTP action fails with an authentication error
Cause: The BAM API URL or credentials configured in the HTTP action are incorrect.
Fix: Retrieve the correct API URL and authentication details from Business Activity Monitoring > Actions > BAM Connection details.
Stage status is not updating after a Checkpoint call
Cause: The BAM-StageStatus header value does not match an expected stage status value.
Fix: Confirm the valid stage status values defined in the business transaction stage configuration.
Tracked data from the Standard workflow is mixed with Consumption workflow data
Cause: Both workflows are sending events to the same business process and transaction.
Fix: If separation is required, create distinct business processes or transactions for Standard and Consumption workflow tracking.