Gokan's Studio

Don’t shoot the messenger—just to be clear, this isn’t my opinion; it is a Microsoft guide designed to help my customer.

Microsoft has consistently emphasized that the default environment in Power Platform is open and accessible to all users. This means that anyone in the organization can freely create apps, flows, and other components without requiring special permissions or governance controls. While this approach encourages innovation, collaboration, and rapid solution development, it also introduces substantial governance and security challenges — particularly for governmental or highly regulated organizations.

In such environments, unrestricted access can lead to data leakage, shadow IT, and a lack of oversight over what is being built and shared internally. Consequently, many public, military, or highly confidential sector institutions and enterprises are actively working to define stricter boundaries and implement governance strategies that limit the scope of this default environment.

In collaboration with a Microsoft sub, we conducted a series of tests to understand better how this default openness operates in practice, evaluate potential risks, and identify effective methods to control and restrict access while maintaining flexibility for approved users.

Do you also want to restrict the default environment?

Yes?

Let’s go!

Step 1

If you already have access to the Power Platform, reaching the default environment should be straightforward. You should have no trouble creating and saving apps there.

Step 2

From the Default Environment -> under the Advanced Settings, which will bring you to the Dynamics page, navigate to Security -> User -> and validate the current security Settings of the user whose access you want to change.

In normal circumstances, if you’re not a global admin or Power Platform admin, the user has the default assigned security roles in the system:

• Basic user
• Environment Maker
• …

And especially, this Environment Maker Role grants users the ability to create apps and flows. 

During our investigation, we noticed there is even a Microsoft-supported way to limit access to the user. There is an out-of-the-box security role called App Opener. See: Role-based security roles – Power Platform | Microsoft Learn

Step 4

Let’s now assign this new App Owner role to the user (and remove all other security roles, including the existing Environment Maker Role). We’ll now further test it with the App Owner Role only assigned to the user.

Step 5

Save the security role assignment and refresh the users’ Power Apps interface windows. When we try to view solutions, you’ll now see that this is failing due to missing privileges.

Even if you try to create a solution, as you don’t have the correct permission level, you’ll get the following error.

Despite this, a user can still create Canvas Apps in Power Platform. Even if all security roles are removed, the ability to develop Canvas Apps remains. Consequently, simply modifying security roles is no longer enough to prevent app creation. But luckily, there is now a feature (no longer in preview —allowed for production use) that requires all apps and flows to be created within a solution.

This will bring us to our solution. (see: Add canvas apps and cloud flows to a solution by default – Power Apps | Microsoft Learn)

Step 6 

Enable the feature that all apps and flows need a solution

This feature is disabled by default. You must enable it before you can use it.

1. Sign in to the Power Platform admin center and select an environment.
2. Go to Settings > Product > Features.
3. Under Create new canvas apps and cloud flows in Dataverse solutions, turn on Canvas apps (Preview) or Cloud flows as desired.

Step 7

Create an app and try to save it:

Now, when we try to create an app and save it, the system throws an error.

You can no longer create any apps. In Power Automate, users with this security role and settings will give you an error message where you can’t save your flow anymore.

It’s as easy as a next-next-finish SharePoint Server Installation.

Now, if, for some reason, a new security role is still needed (adapt own privileges), these are the steps you could take: First, let’s copy this maker role and remove the Canvas App Create Right.

Please give it a name and save it. In our case, we named it Environment Maker No Create App and Let’s now adapt the new security role

I hope it’s clear that there are settings enabled to configure the default environment so the user cannot create any more apps or flows.

During this setup, we followed all steps in my own custom tenant and used users with premium licenses. I didn’t test it with users without a premium license, but I would assume this isn’t affecting the solution.  

Automation

There are PowerShell equivalents, but not (yet) official Microsoft documentation around this topic. Example from the community:

# Retrieve your custom security role. Replace “Custom Role” with your role’s name.
 $roleName = “App Opener“
$role = Get-CrmRecords -EntityLogicalName “role” `
 -FilterAttribute “name” -FilterOperator “eq” -FilterValue $roleName
 if ($role.CrmRecords.Count -eq 0) {
Write-Output “Custom security role ‘$roleName’ not found.”
} else {
 # Assign the role to the system user.
 $systemUserId = [retrieve dynamicly or set manually]
$roleId = $role.CrmRecords[0].roleid
# Use the relationship name for system user roles; by default it’s often “systemuserroles_association”.
 Add-CrmRecordAssociation -EntityLogicalName “systemuser” `
-RecordId $systemUserId `
-Relationship “systemuserroles_association” `
-RelatedEntityLogicalName “role” `
 -RelatedRecordId $roleId
Write-Output “Assigned security role ‘$roleName’ to system user with ID: $systemUserId”
}

Because this procedure is highly controversial and seems to contradict much of what we’ve heard until now, I asked my good friend Gilles Pommier to examine it closely, test it, and share his insights with me. Here are a few things that he sent over to me

1-Canvas apps are blocked, but not templates

The procedure works, but ensure that the “Environment Maker” role has been removed. However, users can still create Power Apps Canvas App templates—this remains unblocked. All other actions are correctly restricted.

2-Make sure that the Default Environment has Dataverse

I tested this in an environment where the default environment didn’t have Dataverse, and it failed completely. Ensure that Dataverse is enabled in the default environment.

3-Eecuting Apps also looks blocked even with the App Opener role

After testing for a while, even running apps felt complicated, which seemed strange.

4-Add the Template App-ID at the end, and you can still save your Canvas Apps

As stated earlier, you can still create templates with Power Apps. But, if you add the app-id at the end of the URL, you still can save your Canvas App.

 Conclusion

As we’ve seen, the default environment in Power Platform is designed for openness and rapid development. Still, that very openness can pose significant governance and security risks in highly regulated organizations. By carefully leveraging security roles—such as the App Opener role—and enabling the “create apps and flows only within solutions” feature, administrators now have the tools to restrict app and flow creation in the default environment fully.

This approach allows small and mid-sized organizations to strike a balance: maintaining flexibility for approved users while enforcing strict controls to prevent unauthorized or unmanaged development. With these steps, you can confidently block the default environment and align governance with your organization’s policies, without compromising the platform’s integrity.

References

https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/sample-associate-security-role-user?view=op-9-1

https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/sample-remove-role-user?view=op-9-1

Hope that helps,

Renewed Revolution!