There has been 400 flow runs done and need to find one certain run – no problem, this is 5min job with Application Insights log search. With that you can get the url for exact flow run and start debugging, instead of going trough hundreds of flow runs…
Microsoft Learn gives you just basics for error handling, but there is better way for handle errors and log all Power Automate flow instances to a single place in Azure Application Insights (1). For core users and users testing the solution and integration by giving readable messages in Teams channel (2). There are hundreds of patterns for copy try-catch-finally logic but I did a bit different way mine.
Application Insights collects history data from logs and exceptions. There is direct view for exception and automatic alerts. Application Insights offers a lot of possibilities to search log history. Application Insights are for developers and maintenance teams and requires more technical knowledge.
Teams logging will help testing integrations and flow functionality. Teams logging helps developers, that they don’t have to dig so deep every time something is not working. With Teams channel logging testers can see when error happens, not seek for functionality not working later in testing.
Above is the structure of the example flow. Functionality A is something, then B and C are done parallel. There could be more functionalities in parallel paths or after each other in one path. There could be also functionalities after path B and C. Now there is just finalization in the end. With this structure it is easy to move modules from point to another without having to reset the ”run-after” settings for scopes. This structure ensures that after failure flow will continue. If you want to stop executing flow, implement terminate action inside ”nnn Failed” scope as the last action.
Structure inside functionality. There is execution scope and then there is scope if execution fails. When action inside functionality scope is failed, it will start executing failed scope because it is configured to run after execution scope has failed. Inside failed scope there is logging with understandable language to Teams and then to Azure Application Insights with Azure Function for more technical details and history data.
Application Insights is for logging information that I can return back to the flow run afterwards directly – without having to go trough all flow instances. I can order alerts from Application Insights Errors – without having to follow separate flow pages or receive multiple emails for each error.
Teams logging in more detail
In the beginning of the flow I post an adaptive card to Teams channel for inform that this flow is started. It does not need to be at start, if you need to do some other functionality before informing the core users. In the real solution I use environment variables and other dynamic data for the details.
I write informative messages to users that what has happened and why. Use links if needed, ie. you are creating SharePoint sites, folders or other locations. Inform also when something has failed.
Flow not terminating on errors?
In functionality A the failed scope ends with Terminate action. If you don’t terminate your flow, then use Errors variable like below instructed.
If your flow is not supposed to terminate in functionality B errors, then there is need for variable named Errors. Initialize it false and set to true when there are failed scope.
Then remember to add condition that you post a happy ending only if there were no errors. This way user gets better experience what has happened during flow execution.
Azure Function logging into Application Insights
There is no ready connector to write Application Insights from flow. You need to create this Azure Function App and add there two functions. You can download my classes for logging information, error and request in zip-file. Create a Azure Function (runtime v1) project with Visual Studio, add these classes and add needed NuGet packages (Microsoft.ApplicationInsights, Microsoft.ApplicationInsights.Web and Microsoft.NET.Sdk.Functions) and voila.
I the example link the guy used NodeJS for functions but that is not my specialty, I wanted to use C#. I created two classes, one for logging error and another for logging information. Those could be the same and just parameters define how to call client. These properties can be adjusted to you needs, this is just version 0.1 to do the minimum and log enough information to Application Sights.
I normally use Environment variables in solutions, but since this is my demo tenant without Power Platform licenses, I just created simple flow and set the urls to normal variables in above picture. You can get these url from Azure Portal once published the functions to Function App.
Publishing the functions needed me to get the publishing profile from Function App in Azure portal. Then used that in Visual Studio and published the functions to the Function App. Then I navigates to this Funciton App and selected there functions. When clicking the function LogInformation or LogError you get this screen above this text. Click there ”Get Function Url” you get the url that needs to be used in HTTP Request in Power Automate flow. The code in the end is the authentication, so not anyone can call these functions if know the url.
You need to add compose and parse JSON actions in the beginning of the flow (picture above), so you can use dynamic information when logging to Application Insights. Then you use those parameters for the properties with HTTP request body (picture below). Notice that the FlowUrl is the first id and the TrackingId is the second id, which is giving the actual run id for the flow.
You should use the logInformation for logging all scopes in your flow. These custom properties are just taken from the example, you can choose properties you want think you need when something goes wrong. In this example we don’t use flow exception information, since we don’t know which action fails inside a scope.
The better you choose your custom properties, the better you can do search when flows are have ran days or weeks ago. No need for you the actual flow history or go trough multiple different flows. Here you can see if many flows crash the same time.
With the custom properties you can parse the flow run url. I have not created so, that there is clickable link but in the
