Introduction
Building enterprise integration solutions involves much more than connecting systems and transforming data. Successful integrations must also provide visibility into runtime activity, enabling support and operations teams to monitor transactions, troubleshoot issues, and quickly locate specific business messages when problems occur.
Azure Logic Apps provides built-in monitoring capabilities through diagnostic telemetry that can be published to Azure Monitor and Azure Log Analytics. When diagnostic settings are enabled, Logic Apps automatically emit runtime information about workflow and action execution, providing valuable operational insights.
Out of the box, Logic Apps generate telemetry such as:
- Workflow name
- Trigger execution details
- Action execution details
- Runtime status
- Duration
- Error information
While this telemetry is useful for understanding workflow execution, it does not automatically expose business-specific information contained within message payloads such as XML, JSON, EDI, CSV, or other custom formats. As a result, support teams often struggle to locate a specific transaction using business identifiers such as Order Numbers, Invoice Numbers, Customer IDs, or Message IDs.
Fortunately, workflow runtime telemetry is not limited to technical execution details. Azure Logic Apps also support Tracked Properties, a feature that allows selected business values to be promoted into diagnostic telemetry and stored in Log Analytics.
By using Tracked Properties, organizations can expose the specific business identifiers required for operational support without logging entire payloads. This enables efficient searching, correlation, monitoring, and troubleshooting of workflow executions using familiar business data rather than internal workflow run IDs.
This is precisely the scenario that Tracked Properties were designed to address.
📝 One-Minute Brief
Azure Logic Apps Tracking Properties allow you to expose key business data such as Order IDs, Invoice Numbers, Customer IDs, and Correlation IDs in Log Analytics. This makes workflow executions easier to search, monitor, correlate, and troubleshoot without logging entire payloads.
What are Tracking Properties?
Tracked Properties are custom name-value pairs that can be associated with Logic App triggers and actions. They allow developers to capture and emit selected values from workflow inputs, outputs, variables, or expressions into diagnostic telemetry.
Their primary purpose is to surface business-relevant information in monitoring platforms such as Azure Log Analytics, making workflow executions easier to search, correlate, and troubleshoot.
Common examples include:
- Order ID
- Invoice Number
- Document ID
- Correlation ID
- Customer ID
- Message Type
- Process Code
- Source System
- Business Unit
When diagnostic logging is enabled, these values are captured in the workflow runtime telemetry and can subsequently be queried using the Kusto Query Language (KQL) in Azure Log Analytics.
Advantages and Disadvantages of Logic App Tracking Properties
Tracking Properties are one of the most effective monitoring features available in Azure Logic Apps. They allow teams to expose key business data, such as document IDs, order numbers, and correlation identifiers, making workflow executions easier to search, monitor, and troubleshoot in Log Analytics.
However, like any monitoring strategy, they come with both advantages and limitations that should be understood before adopting them across an enterprise integration landscape.
Advantages
- Makes business data searchable in KQL
- Allows support and operations teams to search for workflow executions using business identifiers rather than technical run IDs.
LogicAppWorkflowRuntime
| where TrackedProperties contains "INVOICE-2026-12345"
- Accelerates troubleshooting and support activities
- Rather than manually inspecting dozens of workflow runs, support teams can immediately locate the transaction they are investigating.
- Cheap and fast
- No additional infrastructure: Tracking Properties are a built-in Logic Apps capability.
- Supports lower-cost monitoring strategies
- Instead of storing entire payloads, organizations can capture only the business identifiers required for support and operational processes, reducing data volume and improving query performance.
- Easy implementation: Can be configured directly from:
- Designer
- Code View
- and supports expressions and dynamic content
- Improve operational dashboards: You can build KQL dashboards and alerts based on:
- Partner
- Message Type
- Process Code
- Source System
- Business Unit
- instead of technical workflow information.
- Avoids exposing sensitive payload data
Disadvantages
- Not designed for full payload tracking
- Tracked Properties should be used for targeted business attributes, not for complete XML or JSON payloads.
- Large payloads:
- Increase storage consumption
- Reduce query efficiency
- Create unnecessary operational overhead
- Additional development effort: Requires governance and standardization:
- Organizations should establish standards that define:
- Which fields must be tracked
- Naming conventions
- Mandatory correlation identifiers
- Security requirements
- Without governance and strategy, different teams may track different information, resulting in inconsistent monitoring experiences
- Organizations should establish standards that define:
- Can increase Log Analytics ingestion costs
- While much cheaper than logging full payloads, every tracked property still generates telemetry data.
- More properties = more ingestion.
- Limited scope per action: Tracking Properties can only reference data available to the action where they are defined. This limitation surprises many developers
- You can add Tracked Properties to actions, but they can only reference the parameters, inputs, and outputs for their own trigger or action.
- Potential security and compliance risks
- Developers must carefully avoid logging sensitive information such as:
- Personally identifiable information (PII)
- Credit card information
- Address details
- Authentication secrets
- Confidential business data
- Once diagnostic data is written to Log Analytics, it may remain accessible throughout the workspace retention period.
- Developers must carefully avoid logging sensitive information such as:
Best Practice
Tracked Properties should focus on answering a simple operational question:
“What information would a support engineer need to quickly locate and understand this transaction?”
In most enterprise integration scenarios, tracking a small set of business identifiers provides greater operational value than attempting to track excessive amounts of data.
A recommended baseline includes:
- Correlation ID
- Document ID
- Message Type
- Source System
- Partner
- Process Name
This approach typically delivers excellent searchability and troubleshooting capabilities while minimizing telemetry volume and associated costs.
Prerequisites
Tracking Properties require:
- Diagnostic Settings: your Logic App must send diagnostics to one of these services:
- Log Analytics Workspace: Most teams use it.Storage Account
- Event Hub
- Workflow Runtime Logs
- Workflow runtime diagnostic events must be enabled.
- Without diagnostics enabled, Tracking Properties will not appear in Log Analytics.
I hope you find this helpful! If you liked the content or found it useful and want to help me write more, you can consider buying (or helping to buy) my son a Star Wars Lego set.
