Manage Power Apps

If you're an environment admin or a Microsoft Power Platform admin, you can manage the apps created in your organization.

Admins can do the following from the Power Platform admin center:

  • Add or change the users with whom an app is shared
  • Delete apps not currently in use

Prerequisites

Manage Power Apps

  1. Sign in to the Power Platform admin center.

  2. In the navigation pane, select Environments, select an environment with resources, and then select the Power Apps resource.

    Select Power Apps resource.

  3. Select an app to manage.

    Select an app.

  4. Select your desired action.

    Share or delete app.

Manage who can share canvas apps

Power Apps respects the Canvas App ‘Share’ privilege in Dataverse. A user won't be able to share canvas apps in an environment if they don't have a security role with the Canvas App Share privilege set to a value other than ‘None selected’. This Dataverse Canvas App Share privilege is also respected in the default environment. This article outlines how to edit privileges in a security role: Edit a security role.

Dataverse Canvas App privileges.

Note

The ability to granularly control the Canvas App Share privilege in a security role requires Dataverse in the environment where the privilege is to be changed. Power Apps does not discretely recognize the other Dataverse Canvas app entity privileges set for the environment.

System updates may remove customizations to predefined security roles, including Environment Maker. This means the removal of the canvas app share privilege may be reintroduced during a system update. Until the customization to the canvas app share privilege is preserved during system updates, the share privilege customization may need to be reapplied.

Surface your organization’s governance error content

If you specify governance error message content to appear in error messages, it will be included in the error message displayed when users observe they don’t have permission to share apps in an environment. See: PowerShell governance error message content commands.

Distinguish Microsoft SharePoint custom form makers from general Environment Makers

In addition to the ability to save SharePoint custom form resources to a nondefault environment, it's also possible to limit maker privileges to only be able to create and edit SharePoint custom forms in a nondefault environment. Outside of the default environment, an admin can unassign the Environment Maker security role from users and assign the SharePoint custom form maker security role.

Note

The ability to distinguish SharePoint custom form makers from general Environment Makers requires Dataverse in the environment where the privilege is to be changed.

A user with only the SharePoint custom form maker role in an environment won't see the environment in the environment list in https://make.powerapps.com or https://flow.microsoft.com.

Do the following to limit maker privileges to only be able to create and edit SharePoint custom forms in a nondefault environment.

  1. Have an admin designate an environment for SharePoint custom forms that is different from the default environment.

  2. Have an admin install the SharePoint custom form maker solution from AppSource to your environment designated for SharePoint custom forms.

  3. In the Power Platform admin center, select the environment you designated for SharePoint custom forms in step one and assign the SharePoint custom form maker security role to users expected to create SharePoint custom forms. See Assign security roles to users in an environment that has a Dataverse database.

Frequently asked questions

Can I edit privileges in the SharePoint custom form maker security role?

No, the SharePoint custom form maker security role is added to an environment by importing a noncustomizable solution. Note, SharePoint custom form creation requires a user to have permissions in SharePoint and Power Platform. The platform verifies a user has write permissions for the targeted list created using Microsoft Lists and the user has permission in Power Platform to create or update the SharePoint custom form. For a SharePoint custom form maker to satisfy the Power Platform check, the user must have the SharePoint custom form security role or the Environment Maker security role.

Will a user with only the SharePoint custom form maker role see an environment in the make.powerapps.com environment picker?

No, a maker that doesn’t have a security role called out in the Choose environments documentation won't see the environment in the environment picker in https://make.powerapps.com. A user with the SharePoint custom form maker role might attempt to navigate to the environment by manipulating the URI. If the user attempts to create a standalone app, they’ll see a permission error.

Power Apps missing permission dialog.

Manage app quarantine state

As a complement to Power Platform’s data loss prevention policies, Power platform enables admins to 'quarantine' a resource, setting guardrails for low-code development. A resource’s quarantine state is managed by admins and controls whether a resource is accessible to end users. In Power Apps, this capability allows admins to directly limit availability of apps that may need attention to meet an organization’s compliance requirements.

Note

A quarantined app won't be accessible to users who have never previously launched the app.

A quarantined app may be accessible, momentarily, to users who have played the app before it was quarantined. These users may be able to use the quarantined app for a few seconds if they've used it in the past. But after that, they'll get a message telling them that the app is quarantined if they try to open it again.

The following table outlines how the quarantine state impacts experiences for admins, makers, and end users.

Persona Experience
Admin Regardless of an app’s quarantine state, an app is visible to admins in the Power Platform Admin Center and PowerShell cmdlets.
Maker Regardless of an app’s quarantine state, an app is visible in https://make.powerapps.com and can be opened for editing in Power Apps Studio.
End User A quarantined app will present end users that launch the app a message indicating they’re unable to access the app.

End users will see the following message when they launch an app that has been quarantined.

Power Apps quarantine end user message: This app could not be launched because the app has be quarantined by the admin.

The following table reflects quarantine support:

Power Apps type Quarantine support
Canvas app Generally Available
Model-driven app Not supported yet

Quarantine an app

Set-AppAsQuarantined -EnvironmentName <EnvironmentName> -AppName <AppName>

Unquarantine an app

Set-AppAsUnquarantined -EnvironmentName <EnvironmentName> -AppName <AppName>

Get an app's quarantine state

Get-AppQuarantineState -EnvironmentName <EnvironmentName> -AppName <AppName>

Conditional Access on individual apps (preview)

In addition to respecting Conditional Access policies applied to the Power Apps service, it's possible to apply Microsoft Entra Conditional Access policies to individual apps created using Power Apps. For example, an admin can apply a Conditional Access policy requiring Multi-factor authentication only on apps containing sensitive data. Power Apps uses Conditional Access authentication context as the mechanism to target Conditional Access policies on granular apps. Admins are the persona allowed to add and remove authentication contexts on an app. Makers cannot edit authentication contexts on an app.

Note

  1. Authentication contexts set on an app are not moved with apps in solutions and moved across environments. This allows different authentication contexts to be applied to apps in different environments. Also, as an app moves across environments via solutions the authentication context set in an environment is preserved. For example, if an authentication context is set on an app in a UAT environment, that authentication context is preserved.
  2. Multiple authentication contexts might be set on an app. An end user must pass the union of Conditional Access policies applied by multiple authentication contexts.

The following table outlines how Conditional Access enforcement on a specific app impacts the experiences for admins, makers, and end users.

Persona Experience
Admin Regardless of Conditional Access policies associated with an app, an app is visible to admins in Power Platform Admin Center and PowerShell cmdlets.
Maker Regardless of Conditional Access policies associated with an app, an app is visible in https://make.powerapps.com and can be opened for editing in Power Apps Studio.
End User Conditional Access policies applied to an app are enforced when end users launch the app. A user that does not pass the Conditional Access checks is presented a dialog in the authentication experience indicating they’re not allowed to access the resource.

After admins associate authentication contexts to Conditional Access policies in https://portal.azure.com they may set the authentication context ID on an app. The following image illustrates where to get the authentication context ID.

Azure Portal Authentication Context ID

End users that don't meet Conditional Access policy requirements receive an error message that indicates they don't have access.

The following table reflects conditional access on granular apps support:

Power Apps type Conditional Access on individual apps support
Canvas app Preview availability
Model-driven app Not supported

Add Conditional Access authentication context IDs to an app

Set-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName> -AuthenticationContextIds <id1, id2, etc...>

Get Conditional Access authentication context IDs set on an app

Get-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>

Remove Conditional Access authentication context IDs on an app

Remove-AdminPowerAppConditionalAccessAuthenticationContextIds –EnvironmentName <EnvironmentName> -AppName <AppName>

See also

Power Apps admin PowerShell support