SharePoint is often used as a data source for Power Apps canvas apps, there’s no getting away from that any time soon. However, this presents additional challenges regarding security, as we need to ensure that our lists and libraries are properly secured.
Unlike sharing a Dataverse-ready application, where we can apply a security role to the tables at the same time, the process is different for SharePoint. As Power Apps specialists, developers, architects and even administrators, it’s important to understand how this works.
In this article, I’ll share my top tips for securing SharePoint lists and libraries that support your canvas app projects.
Table of Contents
ToggleThe risk
A common requirement is to send a link to a document or list item, usually via an email or Teams message. This is quite easy to do in either Power Apps or Power Automate. Unfortunately, this can also expose the URL of the underlying SharePoint site(s).
An inquisitive user might navigate to the site and interact directly with any lists or libraries. This would bypass any conditional access or other logic you may have in your canvas app. For example, you might have a gallery filtering records to show only those created by the logged-on user – but your root SharePoint list might be showing everything.
This, and other scenarios are easy to go undetected. Here’s my rundown of ways to mitigate such risks.
Contribute, not Edit
When a site is first created, three permission groups are automatically applied – Owners, Members and Visitors. A simple way to give users access to create, edit and delete list or library items is to add them to the Members group (either individually or via an AD Group):
However, the Edit permission level is potentially quite risky. It allows users in that group to create items & documents, but also create or delete actual lists and libraries. If you just need members to perform actions against lists/libraries supporting an app, the Contribute permission level works just fine. It allows members of the group to perform the usual CRUD operations, without creating, deleting or changing any infrastructure.
Custom permission level
In Dataverse we can create security roles to control granular access to tables. SharePoint offers the same in terms of custom permission levels. These are basic by comparison but allow for bespoke permissions to be leveraged. For example, the Contribute permission allows users to create, read, edit and delete items, so what if we only want them to create and read?
Site owners can create custom permission levels to be used against lists and libraries:
1- From the site’s homepage, click the cog (top right), then select Site Permissions.
2- From the slide-out pane, select Advanced Site Permissions.
3- Select Permission levels
4- From here, you can either select Add a Permission Level and build one from scratch, or select an existing one and click on Copy Permission Level:
Personally, I prefer the latter; it will have boxes ticked that are standard so you only have to worry about the main permissions you want to grant. Configure to your needs, save it, then apply it to your relevant Permission Groups for your site, lists and/or libraries.Â
Contribute or custom permissions should be handled during the first phases of Power Apps solution development. Try to action these ASAP where you can – security shouldn’t be retrospective.
Turn off Edit in Grid View
If you have full create/edit/delete access to a SharePoint list or library, you’ll see the Edit in grid view option in the ribbon menu:
This option turns the list or library into something akin to an online spreadsheet. Changes can be made instantly without a save button, they could be accidental changes too. Someone could use this feature to bulk-update lots of entries and cause throttling issues. These changes are really hard to reverse if list versioning isn’t enabled (it is by default for libraries, but not for lists).
To disable this option for SharePoint lists:
1- Navigate to the list, click on the cog (top right) and select List Settings.
2- Select Advanced Settings.
3- Scroll down and toggle the following setting to No.
4- Click OK at the bottom of the Advanced Setting screen.
Navigate back to your list and you’ll see the option is now hidden.
It’s an almost-identical process for SharePoint libraries. Navigate to the library, click on the cog, Library Settings, More Library Settings, Advanced Settings, configure and save.
Enable item-level permissions
In our Power Apps, we might configure some logic where users can only see records relating to themselves. We need to remember this isn’t the case by design in our SharePoint lists. Any user finding their way into the lists may therefore see records associated with other people. A quick remedy to this is enabling item-level permissions.
To enable this:
1- Navigate to the list, click on the cog (top right) and select List Settings.
2- Select Advanced Settings.
3- Item level permissions should be the option at the top of the resulting page. Configure both options as per below:
Break and reset permissions
You can extend the option above even further, by using Power Automate to break & reset permissions to the specific list or library item. This will provide an extra level of granularity for access, both for your apps and if anyone stumbles across the backend site structure.
1- Navigate to the Power Automate homepage and select the environment you need to use to build the flow.
2- Create a new automated cloud flow. The trigger will be when an item is created in SharePoint.
3- Configure the trigger to point to the relevant SharePoint site and list:
4- Next, add an action and find the Stop sharing an item or a file SharePoint action. Configure the site and list, then use dynamic content to get the item ID from the trigger:
5- Next, add and configure the Grant access to an item or a folder SharePoint action. The recipients will be who you want to grant access to. This can be users or groups from Active Directory, or dynamic content (ie the Created By from the trigger is usually a good idea). Here you can also specify what role these users will have to the item – Edit or Read:Â
If you need to grant edit & read to different sets of users, you’ll need 2 dedicated actions – 1 for each. Also, don’t forget these actions are compatible with environment variables too, should you have multiple SharePoint sites or lists to support Application Lifecycle Management.
CAVEAT:
Use this method with caution. Breaking inherited permissions to set item-level permissions can be a hassle in the long run. It’s not easy to see who has access to what, or cleaning up access for users who no longer it.
Customise the list form
Even with some or a combination of the above, users may still be able to add or edit items using the native SharePoint controls. Adding or editing an item directly in a list may also bypass logic or settings we’ve configured in our standalone canvas apps. We can customise the default form experience in our SharePoint lists to prevent this. You’ve put all that hard work into building a canvas app, make sure they use it 😊.
1- Navigate to the list, click on the cog (top right) and select List Settings.
2- Select Form Settings.
3- Click on Customize with PowerApps:
From here, you can build the experience you need. Maybe admins can use the default experience but users can’t. Or maybe NO-ONE should be edited through the SharePoint list.Â
I typically opt for the latter, so to customise the list form by removing all default forms/controls and adding my own experience. I’ll usually include a button to launch the canvas app too. Don’t forget to publish the app, else the changes won’t be visible in the SharePoint list.
With this in place, when users try to add or edit an item, they’ll see your revised list form experience:
CAVEAT:
Sometimes this can be a bit temperamental. If you’re customising the list form for the first time, it might not show the changes right away. You may have to return to List Settings > Form Settings, modify and republish the revised list form, before the experience will show in the list.
Hide the list completely
If all maker and admin activity is performed in Power Apps, you can opt to hide the SharePoint list(s) completely. You can do this via PowerShell or Power Automate, I’ll focus on the latter method here.
1- Navigate to the Power Automate homepage and select the environment you need to use to build the flow.
2- Create a new instant cloud flow. The trigger will be manual.
3- Add the Send an HTTP request to SharePoint action. Configure the action has shown below, ensuring you type the display name of your relevant list in the Uri field. In the body, we simply use a boolean to show or hide the specified list:
Configuration if you want to copy & paste:
Uri:
_api/web/Lists/getbytitle(‘Display name of your list’) – don’t forget the single quotes either side!
Headers:
X-HTTP-Method / Merge
If-Match / *
Body:
{
‘Hidden’: true
}
To unhide, run the same flow but change the boolean in the Body to false.
Be wary of Equals [Me]
Something I see a lot is the ‘Equals Me’ method for SharePoint security. This is done by adding a Person or Group column, and then configuring view filters like so:
If this is the only method you’re using for locking down your lists or libraries, please note this is purely a cosmetic thing. Another user could send me a link to one of their items and I’d still be able to edit or delete it!
This method is otherwise known as security by obscurity, so if you want to ensure robust access to SharePoint lists, especially ones supporting your Power Apps, please opt for using other methods detailed in this article.
In a perfect world, Dataverse would be everyone’s primary data source to support Power Apps. Until then, SharePoint lists are, and will remain a widely used tool on which to build Power Platform solutions.
If you’re using SharePoint lists to support your apps, how are you securing them to ensure compliance & integrity? If you’re using any methods not listed above, please let me know in the comments below!
Hi Craig,
Thanks for sharing
I also enjoy the session you give together wit Michael Roth at the EPPC in Brussels.
Thanks Yves! Glad you enjoyed the workshop, we had a great time delivering it
Create Tips Craig and good to have you back after a short “blogging” break, I guess. Particularly liked the REST API one to hide/unhide.
Hi Craig,
sending the Power Apps canvas app data to a Power Automate Flow to create/edit the item and setting the proper SharePoint connection (the one of the Flow’s owner), you can remove any users’ permission on the list.
In case a canvas app is not needed and you don’t have any lookup columns, you can use the new List Forms functionality providing the users with just the Form’s link and no List access permission.
ciao, Sergio
Thanks Sergio, good to know!
Your blog post couldn’t have come at a better time. At my workplace, we’re currently determining the best approach for data modeling in our project. Specifically, we’re exploring how to secure the ‘tables’ created in Microsoft Lists, even though we know Dataverse is the preferred option due to its robust security roles.
Thank you!
Thanks, Martina! Agreed, Dataverse wins hands down but some orgs still aren’t able to move over financially. So hoped that this article would still help those that are still trying to make the best of SharePoint/MS lists
Hi Craig – really handy summary! One issue I have run into is with custom permissions groups and using flow to give permissions to site groups. If a group has custom permissions levels, flow doesnt seem to like it and the group doesnt get added. If a group uses a pre-exisiting permission level (one of the default three), even if it is modified, then it works!
Hi Sam, agree Flow can sometimes be a pain for handling permissions using the native actions. Doing so through the SharePoint REST API can sometimes be better for working with both custom and native perms
Hi Craig – thanks for a very useful article! My organisation is currently looking at this. Is there a way to stop users connecting to the list when creating a new power app? We can lock things down so the list can’t be accessed from sharepoint but when creating an app they can add the list and see everything.
Hi Nikki,
The only way to stop a maker adding a SharePoint list to an app is to remove their access to the list, or even the site. Power Apps will honour the SharePoint permissions as it’s just an interface over data, so double check their permissions on the SharePoint side.
Thanks for the very quick reply Craig! We tried removing access to the list but it then stopped them being able to use the app unfortunately. We’re able to lock things down so users can only see their own records in the list but that doesn’t help for a situation where a manager needs to see records relating to all their delegates. Just wish we had the funds to use Dataverse!
The only way you can really do that with SharePoint lists is via a Power Automate flow. Use the SharePoint REST API to break inheritance when an item is created, then use it again to reset to the specific persons. It will create a fair amount of debt in terms of ongoing management, but it will give you what you need.