An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.
Hello Karthik K Koneru,
We understand that you have an APIM API that pushes messages into an Azure Service Bus Queue. Logic Apps consume these messages. You want to locate the Logic App workflow Run ID that processed a specific message, but the Logic App run history blade is impractical due to high execution volume. You’ve tried searching Application Insights traces but couldn’t find the Run ID directly.
When a Logic App is triggered by Azure Service Bus:
-
operation_Nameshows the trigger or action name (e.g.,ServiceBusTrigger,When_a_message_is_received_in_a_queue) - The Logic App Workflow Run ID is not shown in
operation_Name. - Application Insights correlates all telemetry for a single Logic App execution using:
operation_Id - Every action and trigger in the same workflow run shares the same
operation_Id.
The most reliable approach is to add the business identifier (like Order ID) to Application Insights at the start of each Logic App run. When you do this, every workflow run can later be searched by that Order ID and clearly linked to its Run ID. If you don’t add this extra tracking, the Run ID isn’t always visible in the default logs, which makes it hard to match messages to runs when there are many executions.
In Consumption Logic Apps, you don’t need to log manually if you use trackedProperties; the Run ID is automatically included in customDimensions["workflowRunId"]. If you want full control (or need additional custom logs), logging JSON like this works:
{
"OrderId": "@{triggerBody()?['OrderId']}",
"RunId": "@{workflow().run.id}"
}
Then query via:
customDimensions.RunId
Best practices for easier lookup
Tracked Properties: Push the business identifier (Order ID) as a tracked property in the trigger or first action.
- Automatically appears in
customDimensions["trackedProperties.<Name>"] - Queryable without manual logging
Custom Tracking ID / Correlation ID: Use a correlation ID (e.g., a GUID or Order ID) propagated from APIM or your source system. This allows end-to-end correlation across multiple systems, not just the Logic App.
Always log both Order ID and Run ID together to allow a direct query.
Example query works fine: use tracked properties instead of logging manually:
traces
| where customDimensions["trackedProperties.OrderId"] == "<OrderID>"
| project timestamp, workflowRunId = customDimensions["workflowRunId"], message
You can pivot on operation_Id to see all telemetry for a single run. This is useful for troubleshooting when a run has multiple actions and multiple dependencies.
Here is the sample KQL Queries
Find the Logic App run for a specific Order ID: Returns the run(s) that processed that specific Order ID.
traces
| where customDimensions["trackedProperties.OrderId"] == "<OrderID>"
| project timestamp,
workflowName = customDimensions["workflowName"],
workflowRunId = customDimensions["workflowRunId"],
actionName = customDimensions["actionName"],
message
| order by timestamp desc
Pivot all telemetry for a specific run using Run ID: Shows all actions, steps, and traces for that Logic App run.
traces
| where customDimensions["workflowRunId"] == "<RunID>"
| project timestamp,
operation_Name,
actionName = customDimensions["actionName"],
message
| order by timestamp asc
Use Correlation ID for end-to-end tracking: this is useful if multiple systems produce telemetry for the same business transaction.
traces
| where customDimensions["CorrelationId"] == "<OrderID>"
| project timestamp,
workflowName = customDimensions["workflowName"],
workflowRunId = customDimensions["workflowRunId"],
message
| order by timestamp desc
Hope this helps! If you encounter any issues, please reach out to us. Thanks.