How to Find Azure Logic Apps Workflow Run ID from Application Insights

Select Language:

If you’re working with an API Management (APIM) API that sends messages to an Azure Service Bus Queue, and you want to find out which Logic App workflow processed a specific message, here’s an easy way to do it without having to sift through tons of run history.

When your Logic App is triggered by messages from the Service Bus, some useful things to keep in mind are:

The operation_Name in telemetry shows whether the trigger or action is, for example, “ServiceBusTrigger” or “When a message is received in a queue.”
The Logic App Workflow Run ID isn’t shown directly in the operation_Name.
All telemetry data related to one Logic App run is linked with the same operation_Id.
Each trigger and action within that run share this operation_Id, making it a key to connect the dots.

However, because this information isn’t always obvious, the best way to reliably identify the run that processed a particular message is to include a unique business ID—like an Order ID—in your telemetry right at the start of each Logic App run. Doing this lets you search by that ID later and find the exact Run ID associated with your message, making troubleshooting much easier when you have high message volumes.

If you’re using Consumption Logic Apps, you don’t need to manually log this, because setting trackedProperties will automatically include the Logic App run ID in the customDimensions["workflowRunId"]. But if you want full control or to add custom logs, you can include your tracking info manually.

Here’s how you can set this up:

First, add a “Compose” action immediately after your Service Bus trigger. This Compose action will create a JSON object that captures your Order ID from the message body, like so:

json
{
“trackedProperties”: {
“OrderId”: “@triggerBody()?[‘contentData’]?[‘orderId’]”
}
}

You can add this JSON directly in the Compose action by going to Settings, then adding the trackedProperties. This step ensures the Order ID is carried through the entire run.

Once that’s in place, after your trigger fires, you can query your Application Insights logs using the Order ID. Here’s an example of a query you can run using Kusto Query Language (KQL):

traces
| extend Properties = parse_json(tostring(customDimensions.prop__properties))
| extend trackedProperties = parse_json(tostring(Properties.trackedProperties))
| extend OrderID = trackedProperties.orderId
| extend resource = parse_json(tostring(Properties.resource))
| where OrderID == “”
| project timestamp, OrderID, RunID = resource.runId
| order by timestamp asc

Replace <your-order-id> with the actual ID you want to track. This query will return the exact run or runs that handled that message, along with their timestamps and Run IDs.

Following this approach makes it much easier to match messages to their processing runs—especially when working with a high volume of messages. If you run into any issues or need more help, don’t hesitate to reach out.