Previously I have written some blog post, like this one, showing how easy it is to create API endpoints in Flow and Logic Apps. This involves creating a workflow that gets triggered by an Http Request with a Json payload.  There are asynchronous “fire and forget” API calls and the calling process receives a 202 response code to indicate the workflow has been triggered. When the workflow runs it may call a number of actions across different connectors. Because it is asynchronous the calling process has no idea if the workflow has run successfully or if any actions have failed.

In this scenario tracking down issues and linking them to a specific API request can be difficult especially in a high throughput environment. There is a software pattern called the Correlation Identifier Pattern we can adopt to make these scenarios more supportable. The Correlation Identifier Pattern advises generating a unique identifier called a Correlation Id for each request. The Correlation Id then gets passed to each of the request’s action. That way any action’s success or failure can be traced back to the specific calling request.

We can adopt this pattern easily in Logic Apps and Flow as each workflow run generates a unique Run Id. The Run Id is also known as the Identifier or Correlation Id depending on which portal page you are on.  The calling process can acquire the Run Id from the response header tagged x-ms-workflow-run-id and log it as required with their request. 

When you view the run history for a Logic App workflow you can see the all the runs with their identifiers. The Run Id also get passed to any child workflows so you trace it across these as well.

You can access the Run Id from your workflow and use it in your actions.  In the workflow designer you can use the expression workflow().run.name to the get the Run Id. In my example I added a custom field to the CDS contact entity called Correlation Id, which I populate with the Run Id.

I also added the field to contact form’s footer.

Just one thing to note that is you can use this technique in Flow however the Runs Id are not displayed on the Runs details screen so you need to log the Run Id elsewhere as part of the workflow.

Now when you partner calls support enquiring about an API call problem they can use the Run Id to track exactly what happened.