Using Client Tracking Id for Tracking Purposes in Application Insights

When building integrations (interfaces) there is usually a need to track a transaction id so that you can easily identify the instance of a logic app run that serviced that request. Often, there is also a business context that also gets attached to a running instance. These identifiers are usually in the form of a work order id, employee id, order number, transaction id, etc.

Logic Apps has their own internal tracking mechanisms including the run instance id that allows you to uniquely identify a run from within Run History. But, how can we track our own business context without introducing custom components? The answer is hidden in the settings of your Trigger!

If you click on your trigger and then navigate to Settings, you will find the opportunity to provide a Custom Tracking Id. This value can be hard coded, if that makes sense for your scenario, but otherwise you can use an expression and extract a value from your inbound request. For the purpose of this post, I am going to extract a query parameter called id that will be captured at runtime, but this value could come from the body of the request as well.

Now if we go ahead and run our logic app, we will find this value captured in our Run History.

Note: If you don’t provide a value within the Custom Tracking Id property, the Logic Apps runtime will inject the run instance id for the execution.

What can we do with this value?

The Logic App that I am using for this blog post is based upon the Logic Apps (Standard) runtime. When using this runtime, I have included my telemetry to be sent to Application Insights. With my telemetry being stored within Application Insights, I can subsequently query it. This allows an operations team to easily debug scenarios when a business user is looking for the status of a particular transaction id.

To discover our related records, we can open Application Insights and then perform a Transaction Search. From there, we can add a filter where we will set prop_clientTrackingId equal to the value of our transaction id (in my case 1). We can then view the results of our query. What we find is actually quite comprehensive. We can see when our logic app started, when it completed and the start/end information for each action that was called in our workflow. Essentially, our Client Tracking Id is acting as a custom correlation id for us and linking all these records together.

Conclusion

As we have seen, we have a powerful feature available to us that is hidden within the settings of our trigger. By populating a Custom Tracking Id, we can take advantage of existing Logic App telemetry pipelines that allow us to query for data within Application Insights.