Overview

When building integrations or business process flows using logic apps, often we distribute the execution over multiple logic apps for simplicity of workflows and better management. It is essential to maintain a robust tracking of messages across the complete process flow. This can be achieved using Custom Tracking ID in logic app workflows.

Most triggers have a Custom Tracking ID property where you can specify a tracking ID using an expression. You can use this expression to get data from the received message payload or to generate unique values.

If you don't specify this custom tracking ID, Azure automatically generates this ID and correlates events across a workflow run, including any nested workflows that are called from the parent workflow.

---

Problem Statement

Let's consider a simple business process flow spanning over multiple logic apps and service bus queue as depicted below.

If we do not set a custom tracking ID, then LA1 will use its run instance ID as the tracking ID. Since child workflows use the same tracking ID as their parent, LA2 will use the same tracking ID as LA1. But in the case of LA3, since it reads messages from a queue, it will have a disconnect in between and LA3 will have its run instance ID as the tracking ID.

If we process a message through the above business process and let's say it failed at LA3. For investigation purposes, we need to identify all workflow runs for this failed message. However, it is difficult to trace back message-specific workflow instances without establishing any correlation between them.

Here custom tracking ID can be used to establish that correlation across the processing path.

---

Solution

Custom tracking ID property available in trigger settings. It can read any property value from trigger outputs as long as we can build an expression to retrieve that property.

Let's set custom tracking ID across all logic apps. For this demo, we will use Logic app standard resource.

LA1

Below are some ways to set custom tracking ID in logic app workflow trigger-

1. For HTTP request trigger, we can pass a header parameter x-ms-client-tracking-id with a unique ID value to be used as a custom tracking ID. With this option, you don't need to set a custom tracking ID expression on trigger, workflow will use this header value directly.

   

2. Add an expression to read a unique identifier from the message body/payload. For example, in the below screenshot, I have added orderId as a custom tracking ID on LA1.

   

3. If we are using splitOn configuration with logic app trigger, still we can set any property from individual messages tracking ID.

   

   It will reflect as below in the designer view.

   

For this demo, we will use splitOn with a custom tracking ID configuration.

LA2

Since LA2 is a chid flow of LA1 i.e. it is invoked by LA1, it will use the same tracking ID as LA1 and no need to add an expression for a custom tracking ID.

We need to send tracking ID property value into the service bus message so that it can be retrieved and used by LA3 to maintain the same correlation. Thus, while sending a message to the service bus queue, we can send this orderId as correlationId along with the message.

LA3

Read correlationId from service bus queue messages with the expression "@triggerOutputs()?['body']?['correlationId']" and use it as custom tracking ID.

---

With this, we have set up a common custom tracking ID across all logic app workflows. To test it, let's send a payload with 2 orders in JSON array using Postman. LA1 will split these two orders and process them individually. If all configurations are correct, then they will flow till LA3 and complete the processing.

If we try to search these orders in the Application Insights transaction search, we will get all the execution logs as below.

You can also write a query and find logs related to a custom tracking ID property.

---

Conclusion

This way, all three logic apps have the same tracking ID and give us trail for execution for a particular message when searched through logs. This setup gives us better visibility on transaction processing and helps to analyze failures in a better way.

Thanks for reading! If any feedback please share in the comments.

Keep learning!