In a post I wrote a while ago, I explained how to create a SharePoint custom permission level and special SharePoint groups to be used in Power Apps using PnP PowerShell. And also how to break the permissions on the specified site lists while granting access to the new groups only to those lists. Then, the users from those groups would be able to access the lists only from the app interface and not from the SharePoint UI.
If they tried to open it from the SharePoint interface they would get an access denied message:
This scenario was ideal in case a SharePoint site was used to host the app lists, and more information that might be used by other people from SharePoint, so you would restrict only access to specific lists and not the full site.
Restricting the full site
There are cases where a SharePoint site is used only as a container for lists to be used in a Power App, so it will make more sense to not break permissions in the list, and instead to simply change the permission levels for the site members on the site directly.
Some people have asked me if we can do the same configuration from the SharePoint UI, and also if it was possible to limit access to the full SharePoint site. Both are possible, check the configurations needed below.
Custom Permission level
Consider a Power App connected to a SharePoint site where you would grant access to people using the members group. For this case, we can reuse the same group, but we need to change the permission level to a custom one.
First of all, we need to create a custom permission level.
Note: The steps below will work for Classic Sites, Communication Sites and Team Sites that are not connected to Office 365 groups.
To begin, navigate to the Site Contents page:
Open the Site Settings page:
Then navigate to the Site Permissions page:
And select permission levels:
On the Permission Levels page, select the Contribute permission level:
On the permission level settings page, don’t change anything.
Instead, scroll to the bottom and click Copy Permission Level, so a copy of the Contribute permission level will be created. We then tweak this copy instead of the default Contribute permission level.
On the Copy Permission Level Page, give your new permission level a suggestive name such as Contribute From PowerApps.
Unselect the permission option View Application Pages. This is the option that would grant the user the rights to see the data from the SharePoint pages/interface.
Save your changes to create the new permission level.
Changing the site Members’ permissions to the ‘Collaborate from Power Apps’
Back to the Site Permissions page, select the Site Members group and edit its permissions:
Unselect Edit or any other level in case you had changed it previously, and select the new permission level:
After confirming, the new level is applied:
When a user that is not a site owner, and has access to the app data only from the new permission level opens an app that uses lists from a site with the above setup, the results are normally displayed:
But when trying to open any list or the root site, will get an access denied message:
Now your app users won’t be able to bypass the app rules and interface by accessing data directly on SharePoint.
Additional notes: As a good practice and to make your life easier, you can create an Azure AD/Microsoft 365 security group to manage security on the site and the app at the same time. Use this group do add all app/site users. Then you add this security group to the members group on your site, and share the Power App with the group. For new users added, you simply would need to add them to the security group only and they get the right permissions (otherwise there are two pieces to be always managed, one from SharePoint and the other from Power Apps).
Also bear in mind that this approach blocks the users from opening items from the SharePoint UI, but in the same way, they can access data from your apps, if they are smart enough and find the site URL they will be able to bypass your app’s rules/permissions by creating another app connecting to those lists or using the SharePoint APIs in any way. So if you are looking at blocking it even in that way, additional treatment would be needed such as item/folder level permissions to prevent items to be viewed and/or Remote Event Receivers to implement rules when saving data.