The ask, introduce some better error reporting for a troublesome production cloud flow. The maker just recently deployed their solution to PROD, with some pretty good error handling, but this flow is experiencing some quirks not seen in DEV or QAT, so there are more errors than expected. And unfortunately, each error handled action sends a generic “something unexpected happened” email to the support team, resulting in hundreds of vague emails. So, two things need to happen:
Firstly, more context needs to be added to the cloud flow’s overly vague error emails. The flow is triggered frequently, so there are hundreds of successful flow runs with just as many failed actions, so better error reporting ultimately helps the maker and the support team triage things.
To quickly grab some much-needed context for the error emails, initialize an object flow variable, then assign the workflow() function as its value. This function returns a snapshot of cloud flow details for the current flow run, providing flow run context helpful for the support team.
The object variable now includes helpful workflow values, such as flowDisplayName, environmentName and logicAppName properties of “tags” object, and the “run” id value.
Using these values to add context, flowDisplayName can be included in the email subject line, specifying exactly which cloud flow had an issue:
E.g.,
variables(‘workflowObj’)[‘tags’][‘flowDisplayName’]
Additionally, initialize a string variable and build a dynamic link to the cloud flow run using the environmentName, logicAppName, and id of values of the object properties:
E.g., https://make.powerautomate.com/environments/{{environmentName}}/flows/{{logicAppName}}/runs/{{id}}
Secondly, with the cloud flow context added to the error emails, the number of generated error emails need to be reduced. This maker’s solution is decently robust, so there are at least 5 larger actions expected to potentially fail from time to time. For each bad flow run, that could result in 5 error emails again, per flow run, which quickly adds up:
Alternatively, the flow maker could initialize an array variable, then append personalized error message for each handled fail action. Now, instead of sending an email per failed action, error messages are appended to the array variable and those array items can be exported in a single email action at the end of the flow using the join() expression and “<br>” as the delimiter.
Also, this email can be nested within a Condition action to only send the email if the array isn’t empty:
Adding context to the mail? Complete. Reducing the volume of error emails? Complete. But quick additional bonus, the text being appended to the array can be completely personalized and provide as much context as necessary, per failed action, giving the support team all of the information they would every need to troubleshoot future failures:
Conclusion:
Handling errors is fine. Reporting errors is fine. But handling AND reporting errors with proper context is better. Adopting an approach like this virtually eliminates vague error emails, making them more informative and reducing the number of error emails sent per flow run, not overwhelming the support team’s Inbox.
“The function, the very serious function of racism is distraction. It keeps you from doing your work. It keeps you explaining, over and over again, your reason for being.”
Toni Morrison
#BlackLivesMatter
console.log('Charles'); 
Pingback: Power Automate: Cloud Flows + Better(er) Error Reporting | console.log('Charles');