I'm building a marketing studio time request app that doesn't contain personal information but business sensitive information from the point of view that we don't want people to see other people's submissions due to the inernal politics that might result from it.
I am setting up the powerapp so that staff can submit their time requests and then can go back into the app and view/edit their own submissions only using a formula based on user. The data source is a SharePoint list. I understand that in order to add/edit from the PowerApp they need to have the relevant permissions for list in SharePoint.
So the PowerApp will act as the front end for the submissions and the SharePoint list will act as the back end for the team processing the submissions.
I don't want people in the organisation to be able to access the SharePoint list and view other people's submissions/list items or have the ability to edit other people's submissions/list items.
I could hide the SharePoint list as much as I can by not having it on navigations etc and even create a default view that contains bare minimum info in case someone does navigate there but I feel it's still open to being discovered and information viewed. This is a worry for any future apps that I might create that contain personal data or business sensitive information.
Does anyone have any suggestions about the best way to control this and prevent people from accessing the Sharepoint list that the PowerApp is connected to?
Hi @stevegeall , it's working now. I think my original sharepoint site must've had all sorts of other permissions to lists and documents. I decided not to trace through and just created a brand new site and some new lists. Used the exact same steps and the access control to site and lists work fine now. Thanks very much for your help!
I had trouble getting this to work properly on my existing site that had a couple other projects on it but based on another commenter’s suggestion I created a new site with the permissions levels as described... Then I created a simple test list and then created a PowerApp from that. It worked!
Next I added a data connection to another list and created a drop down that pulled values from it. I ended up giving that list the same special Contribute permissions in order for my tester to be able to see the values (the special Read permissions weren’t sufficient).
Then I added connectors for Office 365 Outlook and Office 365 Users; I didn’t actually use those in any formulas but the connectors were there and my tester didn’t have any issues.
So as long as I don’t share the URL of the list then no one would know what to create a PowerBI report from! Seems like this could be our solution that allows us to hide data without having to resort to item-level permissions within the list!!
Firstly thanks to both of you for the best solution , for power apps users with these custom permissions on sharepoint lists.
So, have tried this with my sharepoint list & site too , it's working as expected , users not able to see the list, but as we have unchecked few features for both READ & CONTRIBUTE permissions & allowed only few, will this anytime effect in future the working of sharepoint lists or in power apps if we use few fields from sharepoint lists, will there be any issues ahead ?
Also as you mentioned about "After stopping the inheritance of permissions on a particular list, and setting the custom permissions level, you may also see a greyed out "Limited Access" permission level. This isn't correct". So even I have seen this on too in lists , sites , so even I didn't see any harm not touching this of limited access as it's by default. So what you say ? will it be better to do the process you mentioned by removing & adding again or is it fine keeping it in the same way?
Kindly look into this it would be really helpful & most needed answer please. Thanks in advance.
This would be the most ideal solution (@Microsoft - please implement this)
Instead of the typical Read, Contribute permissions we would normally assign people on the SP List, if custom permissions can be made called
Read (through PowerApps)
Contribute (through PowerApps)
which are just like the regular versions, but it means the access only works from a PowerApps interface. If the user tries to access the data from a SP List interface directly or REST API for example, then it's as if they have no permission at all.
This also solves the auditing problem since when they make changes to items from powerapps, their current user account will be tracked not some generic service account.
Check out the News & Announcements to learn more.
Did you know that you can visit the Power Query Forum in Power BI and now Power Apps
Power Platform release plan for the 2021 release wave 2 describes all new features releasing from October 2021 through March 2022.
DynamicsCon is a FREE, 4 half-day virtual learning experience for 11,000+ Microsoft Business Application users and professionals.