The great Power Platform governance FAQ

I’ve been talking and “doing” governance on the Power Platform with my colleague Jukka Niiranen since 2020. During that time, I’ve spent countless hours testing and figuring out the small details and nuances. The kinds of details that are not necessary in Learn Documentation for the Power Platform or anywhere else for that matter.

So what’s this FAQ then? In short, it’s a never-ending post to which I will add all my findings over time. The kinds of findings that would not make sense as blog posts on their own but which are still important enough to be documented. You could probably call it a wiki as well but since I don’t have one and have no interest in another platform for one, I’m going to use this soon to be giant post as a means of conveying my findings for the community. Enjoy!

Can a maker publish customizations in the Default environment?

I have a user with Basic User and Environment Maker security roles. I’ve created a solution and I want to publish all customizations. OOTB, publishing as a “normal maker” isn’t possible. We’re given an error that states we’re missing the write permission to Entity, as seen in image 1.

If we add write permission to Entity by using the Role Updater tool in XrmToolBox, we’re going to slowly start seeing progress. Image 2 displays all the privileges that we need write permission to, before customizations can be published. I’ve also listed them below:

• prvWriteEntity
• prvWriteAttribute
• prvWriteRelationship
• prvWriteQuery

Can I import a managed solution as a maker?

A maker has the Basic User and Environment Maker security roles in an environment. They’re able to import a managed solution.

Can I add an additional owner to a flow in a managed solution?

Adding an additional owner to a flow in a managed solution is possible, and an unmanaged layer will not be created. The connection references the flow uses can’t be edited without creating an unmanaged layer (which would be bad). If a new connection reference is created to a flow in a managed solution and an unmanaged layer is thus created, it’s still possible to remove the unmanaged layer and remove active customizations. But why would you do all that to your managed solutions in the first place…

What happens to connection references when I change a solution flow’s owner?

Let’s consider a scenario where a flow is in a solution and connects to SharePoint and Outlook. The flow has been created by our fictional maker Lucius Haily. Lucius has imported his flow as a managed solution to a business critical solutions environment from his own developer environment. As he has manually imported the managed solution, the flow is owned by him and the connection references to SharePoint and Outlook are in his name. Lucius and the admin are wondering what happens to connection references if the admin is made the owner of the flow. Image 3 below illustrates the starting point of this scenario, after solution import. The flow and its connection references are in Lucius’ name.

Let’s change the owner of the flow from Lucius to our admin. This is illustrated in image 4 below.

Looking at the flow details page (image 5 below) we can see that while the flow now as a new owner, the connection references are still in Lucius’ name. Lucius remains an owner of the flow as well – or rather he has “CanEdit” permissions, which we can see by using the List Flow Owners action (image 6 below). What this change means is that the Power Platform requests are now paid by the admin but the connections to SharePoint and Outlook are in Lucius’ name. As we discovered in “Can I add an additional owner to a flow in a managed solution?”, the owner of a flow in a managed solution can be changed without creating an unmanaged layer, but connection references can’t be changed.

Note! These findings apply to solution flows only!

Can I set new connection references for a flow if I re-import a solution manually?

New connection references can’t be chosen when re-importing. The existing connection references as well as flow owners remain the same. Connection references in a managed solution can be changed from an environment’s Default Solution, as managed solutions can’t be edited directly. This doesn’t create an unmanaged layer. When a Service Principal connection exists, for example, for Dataverse, you can change connection references to use the SPN from the Default Solution.

Can a flow become orphaned if it’s shared with someone?

Let’s look at two flows that have been shared with a user licensed with a Power Apps per user license. Image 7 shows a solution flow and image 9 is a non-solution version of the same flow. After the flow has been shared, the original creator owner has been deleted from AAD.

The Get Flow Owner Role as Admin connector returns the following JSON for the solution flow before the creator owner is deleted from AAD:

The Get Flow Owner Role as Admin connector returns the following JSON for the non-solution flow before the creator owner is deleted from AAD:

Observed behavior

When the original creator owner is removed from AAD, and ca. 14 days have passed, the flow is turned off by the platform, and its state becomes suspended. The Get Flow Owner Role as Admin JSON will return the exact same JSON that was returned when the creator user was still in AAD. Is the flow orphaned then? Not really. The original owner is still in the JSON, the CoE Starter Kit still displays the flow’s original creator owner in its Power BI reports, and the environment resources view for Flow in PPAC displays the co-owner the flow is shared with as the flow’s owner (gotta love consistency in the reports). The behavior is the same with both solution and non-solution flows.

Can I share an app that’s in my developer type environment with other users?

You can share an app that’s in your developer type environment with other users. License requirements differ based on the app shared. Developer type environments are meant for personal solution development and not for production apps, even though sharing apps in them is possible. The positioning of developer type environments is very clearly a work-in-progress at Microsoft.

Sharing an app that uses Dataverse

The user the app is shared with requires either a premium license such as Power Apps Premium, a Power Apps trial license, or a Power Apps Developer Plan license.

Sharing an app that doesn’t use Dataverse

A select O365 or M365 license will be sufficient to access an app that doesn’t use Dataverse in a developer type environment.

—————

This article is to be continued with new findings!