I often read/hear that Microsoft Flow is not suitable for the advanced integration scenarios where Logic Apps should be used instead. That statement is probably coming from the comparison below:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-compare-logic-apps-ms-flow-webjobs
This is all great; however, unlike the Logic Apps which are living their own life somewhere in Azure, Microsoft Flow is a first-class citizen in the Power Platform world, so, even if Logic Apps might be more suitable for the Advanced Integration scenarios, Flow might still be preferred in a number of situations.
There are at least a few reasons for that:
Flow is integrated with Power Apps – every user having appropriate permissions will be able to create and/or run Flows:
Unlike the Logic Apps, Flows are solution-aware and can be deployed through the PowerApps solutions. Potentially, that makes them very useful for the in-house solution creators and/or external ISV-s. This is similar to how we’ve always been using classic workflows in the solutions (and not the SSIS, for example, no matter how useful SSIS can be in the other scenarios):
Besides, every fully-licensed Dynamics user brings extra 15K flow runs allowance per month to the tenant, and it’s not the case with the Logic Apps
As such, and since Flows are generally viewed as a replacement for the classic Dynamics workflows (of course once they have reached parity), I think it’s only fair to assume that Flows will actually be utilized quite extensively even in the more advanced scenarios.
That brings me to the question I was asking myself the other day – what monitoring options do we have when it comes to Microsoft Flow? With the workflows, we used to have System Jobs, so a Dynamics administrator could go to the System Jobs view and review the errors.
Although, to be fair, I’ve probably never seen automated monitoring implemented for those jobs.
Still, now that we have Flows, how do we go about error monitoring?
Surprisingly, there are a few options, but neither of them is as simple as the good old system jobs view.
Flow management connector
This is where Flows can manage flows:
https://docs.microsoft.com/en-us/connectors/flowmanagement/
Actually, I am mentioning it here only because this one was a bit confusing/misleading to me. This connector offers a lot of actions to manage flows, but it offers no trigger, and, also, it does not seem to support querying flow errors:
In other words, from the monitoring perspective it does not seem to be helping.
Flow Admin Center
We can go to the flow admin center and have a look at all the flows in the environment, but that does not help with the error monitoring, it seems:
Error-handling steps
As explained in the post below, we can add error-handling steps to our flows. Of course we have to remember to add those steps. But, also, this kind of notifications may have to be more intelligent since, if we ever end up distributing those flows as part of our solutions, we might have to somehow adjust recipient emails depending on the environment. It may still be doable, but it does not seem extremely convenient:
https://flow.microsoft.com/en-us/blog/error-handling/
Also, there are some limitations there. We can’t configure “run after” for the actions immediately following the trigger (whether it’s a single action or whether there are a few parallel actions)
And, also, sometimes we can set up the trigger so that it “fails”.. In which case there would be no Flow run recorded in the history. One example would be an “Http Request Received” trigger when json schema validation is enabled:
Whenever schema validation fails, an error won’t be reported for the Flow. Meaning that this kind of integration errors would have to be tracked on the other side of the communication channel, and that might not even be possible.
Out of the box error notifications
https://flow.microsoft.com/en-us/blog/microsoft-forms-tables-flow-failures/
These could be useful. However, since they are not sent on each and every failure (and, realistically, the should not be sent on each and every failure), the are only useful that much.
Per-flow analytics
There is some good per-flow analytics at flow.microsoft.com
This might be handy, but this analytics is per-flow. And, also, it’s only available for the flows owned and/or shared with the current user.
Of course we can also go to the admin.flow.microsoft.com and see the list of flows, but this kind of charts are not available there.
Admin analytics
Admin analytics comes close:
https://flow.microsoft.com/en-us/blog/admin-analytics/
But there is no detailed information about the errors:
Well, at least we have errors from different flows in one place.. But we can’t see it right away – the data is cached (same way it’s cached for any other Power BI-based report)
PowerShell
Get-FlowRun cmdlet from the “PowerShell Cmdlets for PowerApps and Flow creators and administrators” gives us almost what we need:
https://powerapps.microsoft.com/en-us/blog/gdpr-admin-powershell-cmdlets/
So, if we import required modules:
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Force
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber –Force
And utilize Get-FlowRun cmdlet:
We’ll get Flow runs for the specific flow or for all the flows.. Except that, just like with everything above, a user running this cmdlet won’t be able to get flow runs for any flows which the users does not own and which are not shared with that user.
Afre looking at all those options, there has to be some conclusion, and I’m thinking it’s like this:
From the centralized error monitoring standpoint for Flows, there seem to be no ideal option. One way to make it easier might be by making sure that all “system” Flows are shared with the dedicated support group:
https://flow.microsoft.com/en-us/blog/share-with-sharepoint-office-365/
This way, at least, any member of that group would be able to use PowerShell and/or Per-Flow/Admin analytics to see how those “System” flows have been doing. There will still be no alerts and notifications, but that’s neither better nor worse when compared to the classic Dynamics workflows – that’s pretty much the same.
From the automation perspective, PowerShell looks most promising, just make sure to use Add-PowerAppsAccount cmdlet or the script will be asking you for the user/password (Which is not going to work for the automation):
$pass = ConvertTo-SecureString "password" -AsPlainText -Force Add-PowerAppsAccount -Username [email protected] -Password $pass
Update (May 13): it turned out error monitoring works much better for the solution-aware flows. There is no need to share the flows there, once just needs to have appropriate CDS permissions: https://www.itaintboring.com/flow/error-monitoring-for-the-solution-aware-flows/