Granting Admin Consent for Power App Customized SharePoint Forms

If you have been using Power Apps in your organization, you have likely run into the consent prompt a user receives when accessing an app for the first time. While it is not a bad practice to let users know what has access to their account, admins are aware that these prompts can be intimidating for users and lead to an increase in requests for assistance during the rollout of a new app or customized form.

The Power Apps Administration PowerShell Module provides functionality that allows suppression of the consent prompt for end users by instead providing admin consent, essentially pre-approving the necessary access before it would normally be requested of users.

This can be even more beneficial for SharePoint Forms that are customized with Power Apps as the consent prompts feel more inconsistent as not all sites or lists will have these customized forms.

The cmdlet, Set-AdminPowerAppApisToBypassConsent, can be used for this configuration.

The documented example incorrectly identifies the Power App Identifier parameter as -PowerAppName (as of 3/13/21) while the list of parameters includes -AppName. We can quickly check the available parameters using the Get-Command cmdlet, as illustrated below, to confirm the appropriate parameter is -AppName as there is no -PowerAppName parameter.

Shown here are samples of what a user would see with and without the admin consent process. The user will be prompted for permission (A), listing any connectors used with the form or app. When prompted, they must choose to allow the permissions if they intend to use the form. Should they choose not to do so, they will be dropped into an unhelpful blank form (B).

Choosing to allow the permission request, or if the form has been configured with admin consent, the customized form will instead load as expected no surprise prompt. Configuring admin consent changes the experience, so users get what they expect the very first time they load up the form or app.

Aside from access and the appropriate PowerShell module, the App Id of the customized form is all the information necessary to run the bypass PowerShell command. It can be found in either the Power App Service (GUI) or PowerShell Module (CLI).

Within the Power App service, the form details are found by first navigating to a list with a customized form (or create a new one) and selecting Customize forms from the Power Apps drop down menu. After the Edit screen has loaded, move to the File menu, then click the See all versions button. To the left of Versions is the Details pane, which is where we will find the App ID.

The Power Apps Administration PowerShell Module is needed to identify the App ID from the command-line. With the module installed, we can run Add-PowerAppsAccount and complete authentication via login prompt. The account used must be able to grant admin consent and view all Power Apps in an environment, I will use a Global Administrator, other roles may be reviewed for Azure AD and the Power Platform using these resources:

Azure AD built-in roles – Azure Active Directory | Microsoft Docs

Use service admin roles to manage your tenant – Power Platform | Microsoft Docs

Running Get-AdminPowerApp lists all Power Apps in the default or selected environment. With the command-line method, we do not currently know the name nor the App Id. Fortunately, there is a default naming structure for customized SharePoint forms:

ListName on SiteName forms

In the example below, I have created a site, IntegrationForm, and a list, SampleList. The AppName is the identifier needed to grant Admin Consent.

Site: /sites/IntegrationForm

List: /sites/IntegrationForm/SampleList

Using the default naming scheme then identifies SampleList on IntegrationForm forms as the appropriate Power App.

Having identified the App ID through either method, we can now execute the Set-AdminPowerAppApisToBypassConsent command. Ideally, a Code of 200 will be returned, indicating success. Other codes which may be commonly encountered are 403 and 409 noting a lack of permissions or that the app or form has a session locked for editing, respectively. If the session is locked, it should clear up in a few minutes, so long as there is not any active editing. There is also a -ForceLease parameter that could be added to the Set-AdminPowerAppApisToBypassConsent command, though, this doesn’t appear reliable as of version 2.0.110 of the Power Apps Administration PowerShell Module.

Granting admin consent smooths the first-time experience for users but could cause issues for developers. If admin consent has been granted, users who do not access to run Set-AdminPowerAppApisToBypassConsent will not be able to restore past versions of the app or form. Interestingly, it is still possible to save and publish new versions.

The restore failure can be reproduced in both the browser and PowerShell, neither offer a very clear picture without some digging. Starting with the browser, go to your customized form or a canvas app and navigate to the version history as we did when identifying the App Id. Select a previous version and choose to restore it. For testing, I have used an account which is a Co-Owner of an app and a user which has access to edit forms, otherwise, no administrative roles are assigned.

With customized forms, I have only been able to reproduce an error regarding locked sessions. This may be due to a difference in how a customized form and an app are handled on the back end or may simply be tied to the timing of session releases.

Most browsers have developer tools which can be used to debug and investigate what is happening under the hood of a website. The overview for the developer tools available in Microsoft’s Edge browser can be found here. Two invoke entries can be found using the Network dev tool; they contain the error above about a locked session but another and more informative error as well.

This is message is much clearer; the account does not have the appropriate level of access to perform the restore now that admin consent has been configured.

If we instead try to perform the restore using PowerShell, we get the same message, though, only if the -Verbose parameter is included when attempting the restore. Without it, the command will complete silently and we may be led to believe it was successful when nothing has changed.

The Set-AdminPowerAppApisToBypassConsent command suppresses the first-time user prompt for both Power Apps and customized SharePoint forms, making for an expected and consistent user experience. If you choose to configure admin consent in this way, ensure your development team has the necessary permission to handle version restores or that your procedures detail the separation of responsibilities.