DEV Community

Cover image for Power Platform- 99 Admin Connectors Because 1 Just Won't Do
david wyatt
david wyatt

Posted on • Updated on

Power Platform- 99 Admin Connectors Because 1 Just Won't Do

To support management and administration of the Power Platform Microsoft has taken an unusual approach. Where the standard approach would be baking these tools into the platform, Microsoft has decided to use the platform itself. Everything is an API now then so why not I guess. Using these API's Microsoft has now built 5 Power Automate connectors to manage the platform.

  • 1. Power Automate Management - 23
  • 2. Power Automate for Admins - 8
  • 3. Power Apps for Admins - 19
  • 4. Power Apps for Makers - 16
  • 5. Power Platform for Admins - 33

That's a total of 99 actions, thats a lot of effort that could have gone into the admin and maker portals. Also strange question, but where are the Power Virtual Agent and Power Bi connectors (I get Power BI is the adopted child who isn't really part of the family, but PVA has been since the beginning).

The thing is I can like this approach, I like that we can build our own admin tools, and the CoE tool kit is a good example and starting point, but I just wish it was a little more planned, as it feels like a bodge. Microsoft is an expert at the art of the bodge, but it still feels unplanned, and there are 4 main areas that show this:

1. Incomplete Platform View

Because the platform is built in siloed environments, getting a global view of everything can be very difficult. If I wanted to view every maker, I can't, want to view every flow, same again. There are workarounds (and in number 4 you will see why they are still an issue), but the fact there isn't a detailed granular platform view isn't great for Enterprise customers. The CoE tool kits way of fixing this is to run schedule flows that gather data from each environment and duplicate the data in custom tables in a dedicated CoE environment. If you were planning from the start that isn't the way you would do it (also just to make it interesting its using Dataverse Legacy connector, the only connector that can cross environments, and as the name says, its now legacy).

Want to get detailed logs, that again requires flows running, additional logging and in some instances Azure App insights, who would build an Enterprise platform without baked in auditing at the platform level?

2. Disjointed Applications

When you look at the Power Platform and its history you notice something

  • Power BI - release 2013/14
  • Flow/Power Automate - release 2016
  • Power Apps & Dynamics - release 2016
  • Power Platform - release 2018
  • Power Virtual Agents - release 2019

Power BI, Automate and Apps were all launched separately and before the Power Platform. Only PVA was created after the Power Platform, the rest started as separate programs. Power BI started out from Power Query, Power Automate Azure Logic Apps and Power Apps from Dynamics (thats why Dataverse environments have a Dynamics url and api).

Three different underlying architecture isn't how I would plan one platform. We have PowerFX, but it isn't used in Power Automate or Power BI. We have Connectors that aren't used in Power BI or PVA, the list could go on.

3. Distributed Admin Centers

The coming together of Power Automate and Power App admin center into one Power Platform was a nice move. But that still left Power BI with its own admin center. Then there's Dataverse for Teams, partially administered through Teams admin center. Want to manage your users and licenses, then its the O365 admin center. On top of that you want to use custom connectors with ADD auth you have to create app registration in Azure. These are often controlled by separate teams, so this creates masses of bureaucracy and often gaps in visibility, governance and ownership. If you designed Power Platform from the ground up surely you would want the admin team to have control over everything, from there users to internal API's?

4. Application Life Cycle Management

Originally out of the box there was no ALM, with all deployments done by hand. Now we have Solutions, but this has created 2 different types of flow, that look the same but aren't. Ever tried to list all flows through the 'List My Flows' connector. Guess what you don't see, solution-aware flows. Every flow in a solution is missing.

Tried to share a solution-aware flow through the 'Modify Flow Owners as Admin' connector, you get below error:

Image description

If you want to see how much of a mess it is, check out the table below, I've pulled out flow specific connectors, 10 out of 28 dont work with solution-aware flows, that's a third that don't work.

Image description

There are some workarounds, like Dataverse Legacy for 'List My Flows', and using the Dataverse Unbound action (Grant Access), but they are not like for like for features and require additional complexity.

Solution-aware flows are stored in Dataverse, so the new ".dynamics.com/api/data/v9.1/" api (or rich api) looks like it could solve some of the problems, but the documentation shows this doesn't support non solution flows.

Image description

So that means that currently we have connectors that don't work as expected, and even when a fix comes it is most likely to be 2 different api's cobbled together. Again not something you would plan.

And this is all before we get into the little annoying things, like

  • Apps having to have Service accounts as owners
  • Apps unable to share ownership with AAD groups
  • App sharing not working with Dynamic AAD groups
  • The absence of a 'View/Read only' role for flows and their run history

The Power Platform is a fantastic platform, I just wish Microsoft had a more robust plan instead of the art of the bodge.

Top comments (0)