Possible to implement CoE as an AAD Group instead of an individual?

[ericonline]

I'm interested in standing up the PowerPlatform Center of Excellence, but rather than import the Solutions as myself, I'd like to use an Azure Security Group.

Rationale: We've had two people stand up some form or another of the CoE, and not maintain them, then leave our org so they are in varying states of disrepair.

Rather than worry about a single owner of the CoE and all associated connections (though "connections" may be a different discussion altogether), I'd like to use a Security Group and manage ownership that way. 

Is this possible? If so, what specific permissions does the Security Group need?

[cchannon]

@ericonline I don't have a good answer for you yet, but I like your questions, so let's give this a shot.

So when you say, "...not maintain them... varying states of disrepair..." what exactly are you referring to? Are you saying that these folks who installed the solutions somehow failed to share them with others, so when they left no one was holding the keys?

I am going to take a guess here and say that we're probably in that same canvas-only world you talked about before, and maybe what's going on here is just a disconnect about permissions. You probably don't need to install these solutions as some kind of special identity; you just need to make sure that lots of people have appropriate permissions to access and maintain them. Let me know if it sounds like I'm getting warm here.

[ericonline]

Hi @cchannon , thank you for the continued dialog (and nice to meet you 🙂 ). 

So we have at least 2 CoE's in different Environments in varying states of completeness, setup by people who have left the org. When I view the "CoE Dashboard" app (the only Model-driven app in the org), the data is very stale. Likely because when these folks left, the Flows that feed CoE had failed Connections. 

Might also be because they didn't update the CoE and something "broke". The CoE has had MANY official updates in the past year or so. 

We want to implement a CoE from scratch, but this time do it a better way. Instead of a single individual "owning" the Solution, ideally it would be a Security Group or more likely a Service Principal. Likewise with the Flow Connections. 

This has been a point-of-contention in the past. How do you create a new PowerApp under a Security Group or Service Principal's context? You have to license the SP, set it up with MFA, etc (our folks don't like to do that). How do you securely make Flow Connections using a Service Principal (especially when MFA is involved!). 

So, how would you approach such obstacles? How have others done it?

[cchannon]

Sorry for the long delay there - was on vacation the last week!

OK, so there are a few answers here, none of which you're going to love, but the sum total of them will get you where you want to be.

First, when the solution is imported, some defaults need to be set. Specifically, the person doing the solution import is set as the owner of any "record" customizations being created because someone needs to be the owner. This is why the person doing your imports defaults as the owner. There is no way of overriding this default behavior; you can only go back in after the fact and update ownership to change it to something/someone else.

Now, we need to cover some basics from the model-driven app world, which still intersect all these solution components even though you're only surfacing Canvas Apps. In that side of the house, records can be owned by Users or by Teams, and when owned by a Team, it is as though all users who are members of the team had ownership privs (technically there are other kinds of ownership too, but they don't matter for this conversation). PowerAutomate Flows work this way too, so when you look at the Details on a flow and see the Owners, you can Edit this value and assign other owners of the type User or Team.

But wait - you can't find any teams in that list! What gives? Only one team is created for an environment by default; it is the default team for the root business unit, and you can find it by searching on the name of the environment. By default, it will include all users added to this environment. But you want something different: you want your admins to have access and no one else. To do this, you'll need to create a new team. Go to admin.powerplatform.microsoft.com, pick your environment, and go to Settings-->Users + Permissions--> Teams to add a new team (we'll call it "Admins").

Once you create the team, add all the users you want to have ownership for the Flows as Members of the team. With the team created, go back to your flow, find Owners, Edit, and add the team as an owner. Easy Peasy.

But wait--this is a pain! Do I really need to do this for every powerautomate flow I ever make? Thankfully, no. When users leave the system, they might leave tons of pointers in the background; records of all kinds that they own from Business Process Flows to PowerAutomate Flows to actual system records. If that user was an admin, this could be really complex! Luckily, this is a long-solved problem. Way way way back MSFT solved this dilemma by adding a Reassign Records button to the User form. From admin.powerplatform... go to Security--> Users + Permissions--> Users and click Manage Users in Dynamics 365 to open the classic view.

Open the record of the user who has left your org and you will find a ribbon button for Reassign Records. IF YOU HAVE SYSADMIN PRIVS, This will bulk reassign everything everywhere owned by this user to whomever you choose. This is your magic one-stop-shop for disappearing teammates to make sure no records get orphaned.

So by now you're wondering why all this nonsense with Teams and Ownership instead of just granting privs to an app registration. The reason is that Dataverse automatically - and for every record ever retrieved - evaluates the privs of its core security model when determining who can read/write/delete/etc any resource. Sending the flow (or any other record) off to be owned by an app registration is possible, but it wouldn't solve your problem because all the Users you want to manage it still wouldn't be able to see it. For now, you need to play within the confines of the core security model to ensure their visibility, which I think is best done through team membership and ownership.

[EricRegnier · Accepted solution]

Hi @ericonline,

It shouldn't matter who provision the CoE environment and install the solutions. The issue you're having is with the connection references and its connections which for most of them (e.g. Dataverse) you can setup with a service principal (SPN). This is best practices and shouldn't be configured with a user account, at a minimum with a service account and not a user account. Connection References are a little clunky, but Microsoft enhancements are coming, see below the step to configure them properly.

To setup your connections, create them in make.powerapps.com --> Data --> Connections. Dataverse connection is a little tricky, to setup with an SPN you'll need to:

1. Create a dummy flow and pick any type of Dataverse action/trigger:
2. Click the ellipses on the action and "New connection reference"
   
3. Click "Connect with Service Principal"
   
4. Don't forget to delete the dummy flow and dummy connection reference 🙂

Once connections are setup, create a new solution in the target environment, add all the connection references from the CoE solution (because you can't edit them from the CoE solutions) and bind the newly create connections to them.

Hope this helps!

[ericonline]

Thank you for the details, this is helpful.