Earlier this week I posted a quick video of a prototype app that I created for one of our HybrIT Services clients. In this post the full details on how to create a flow management app in Power Apps.
The problems to solve
In Power Automate it is possible to get the details on a single flow’s run, but what if we want to see all the running flows within an environment? Or how about if we want to view all the running flows in all the environments?
In my post on Sharepains.com, I already explained some more on the need for this solution and the architecture behind the solution.
Developing the solution
I’m going to start with the creation of a solution in Power Apps.
The solution that I’m creating will be called Flow Monitor and I’m selecting my publisher before I’m clicking on the Create button.
That is the first few steps done.
Creating a Table structure to support the data
I’m going to create 3 tables
Environment
Flow
Flow Run
I’m making these tables hold minimum amount of data for this proof of concept. The Pro version of the solution contains more details on the flows. If you are interested in the Pro version then please let me know, either on the chat or by leaving a comment below.
The Environment table
The environments table can be created by creating a new table in your solution. There is no need for any custom columns.
The Flow table
For the Flow table, I’m adding a lookup to the Environment table. The out of the box id field and name field I’m going to keep as they are.
Please note that my columns have an internal prefix of hyb_ this might be different for you if you use your own publisher.
The Flow Run table
The Flow Run table has most of the custom columns on it.
A Lookup to the Flow table
A text field, Error Message to hold any errors reported by failed flows
A start time field
Text field for the flow Status
Now that we have the 3 tables in place we need to populate the data.
First the easy ones before we look at the slightly more complicated Flow Runs.
Populating the environment table
I’m going to use Power Automate to populate the Environments table. Normally I would build in the try-catch pattern, however for simplicity reason, I’m skipping that for now.
I’ve decided that collecting the environments can be done on an hourly basis, therefore I’m configuring the Recurrence trigger to run every hour.
Then I’m finding the environments using the List My Environments action. Each environment that is found is then added to the Environments table using the add a new row action.
Please note that I’m not going to check if the environment already exists in my tables. However, I’m specifically setting the Environment Id to the ID giving to me by the List My Environments action.
This mean that every time the same environment is added again, the Add a new row action will fail, however my flow will continue to add environments that haven’t been added before. Potentially the flow could first check if an environment already exists or not. Once again, I’m trying to keep my flows as short as possible and as simple as possible.
Get Flows flow
To import all the flows in all the environments, I create a flow that is fairly similar to the previous flow.
Once again we have a scheduled flow, that lists all the rows found in the environment table.
Then for each environment we are listing the flows using the List Flows as Admin action.
That is still all easy stuff so far. We should now get our flows populated in our flow list and connected to the environments that the flows exist in. For the Pro version of the solution, I’ve implemented a process that will scan flows for of flow runs more frequently when flows are run more often.
So, depending on the flows we will need to collect more flow runs. One of the reason as we will see later in this post is that the API will only give me the last 50 flow runs for any flow by default. This doesn’t mean that we can’t get more flow runs but we will have to do some more work to catch all flow runs that run very frequently.
Get Flow Runs flow
Now we have to create our 3rd flow. This flow is a bit different.
When should we collect our flow runs? There could be two moments where we want to collect our flow runs.
On a schedule basis
On a demand basis.
However, if we get the app to collect flow run details using the API we are going to risk overloading the API. This over course is something that we should avoid.
Hence, Dataverse is used to hold the flow run basis.
As mentioned earlier depending on flows we want to collect flow runs more or less often, to ensure that we collect all flow runs within our tenant.
Additionally, we should consider archiving records in our flow run table as it is potentially going to be a fast-growing table.
Time to build this flow.
I’m starting with a recurrence trigger that will make my flow run on an hourly basis. I’m then collecting all the environments and flows from my Dataverse tables before I’m processing each environment.
Then you will notice the Get Flow Runs action. This is the action that does all the magic. The Get Flow runs action is a custom connector.
Creating the custom connector will be described in my next blog post. Read part 2 here.