Showing results for 
Search instead for 
Did you mean: 

Removing user ability to access data source without using the app


One of the biggest issues in PowerApps right now is that we cannot protect our data. If we connect any data source to PowerApps (Excel, SharePoint List, SQL Server Connection) it has to be shared with all users for them to be able to use the app.

This creates a problem where user has access directly to data source and can bypass the app to do direct modifications to the data source as well as see information not meant to be seen by them. If your app was built to limit users access to some data, for example:

  1. Showing users only their vacation requests and hiding other user vacations
  2. Showing user only their travel request and hiding other user travels

That means that all users can see all data as well as they can modify it without any trace.


In case of Excel file on OneDrive we need to give users access to this file, that means that user can just go on OneDrive and find the excel file and edit it.

In case of SharePoint List, that means that user needs to have Edit rights to that list and can just find it on the SharePoint Site and go in and edit.

In case of SQL Server Connection, that means that user can open PowerApps, click create new app, open Data Sources and the shared SQL connection will be there and he can connect to it. This will allow the user to see all tables in that SQL connection with edit rights.



I believe the best way to fix it, and this will allow PowerApps to become truly powerful tool to replace most of organization applications is to give the App itself write rights to the Excel sheets, SharePoint lists or SQL Connection and not the user. This way the user will have no access to the files, SharePoint List or SQL Connection and the only way to interact with data will be through the App.

Status: Planned

this work is now planned.   All of the connection types you discuss above are "implicit" connections.  We are currently in arch design discussions to address this. 

Not applicable

Hi @skylitedave


The only thing that would change would be that the App will be given Write/Read rights to the Excel file, SharePoint List or SQL Connector instead of the user getting access. The user identity would not change, and you would be able to limit what user sees and edits in the app. On top of that, you would protect your own data by not allowing user to directly access the data and only through the app. Giving you more control of your data.


I have not looked at any workflow options, but from my understanding there would be no way to secure the data for example in SQL server with any workflow approach, since you already shared the SQL Connector with the end user. The only other solution would be that when you Share the SQL connection with user instead of "Can use" permission there should be an even lower permission setting "Can use only through this app".


Helper I
It's a design problem. As an enterprise solution users shouldn't have been touching database/sharepoint/any sensitive data at all.
Workflows can work around some of the issues, but it's a pain to keep workflows for every single table/list. It's not a good approach if you have to deal with many tables.
Not applicable

This is a must! 

The ideas provided in this topic work for data that is sensitive for non-users of the App/Sharepoint list etc., but insensitive for the users. By that I mean that even if you prevent users to edit other people's data, there is no problem them seeing others data. 

In my case I need to use PowerApps exactly for preventing some users to view data that other users have provided. And PowerApps lets me beautifully filter the data people see when they login based on their credentials. That's absolutely fine. If a group sees the data of another group is my failure as a programmer. However, due to the "read/write to all" permissions the App needs, everyone can see everything in the actual Sharepoint List which is a huge security issue in my case. Creating multiple Sharepoint Lists based on the audience is a no-go because the groups are dynamically changing, both in size and membership, it would be an almost impossible task to keep track of every change and program that accordingly.

It should be very easy to implement the solution, in my opinion. We just need to add a new connection to the same data that would be used only for writing back into the source. We may be losing the 'created by' and 'modified by' statistics, but that can be easily overcome by creating new columns in the source holding the details of users editing the data in PowerApps.

Kudo Kingpin

I don’t agree.  The problem with letting a PowerApp app write back to a SharePoint list (or any data source) is you lose the ability to audit who did what.


Let’s say you were a not so nice developer and you created a PowerApp that allows the app to write back to a pricelist stored in a data source.  Let’s say you let the app change the price from $100.00 to .01.  You have no way to know who made that change if you give the app the ability to write back to the list or data store using a generic ID.


I think it is much better to segment your data and then manage who can access that data so you can audit.  A single screen can connect to multiple data stores by using cards and forms on a card - 2 forms on one screen. 


I have done this for a client where sensitive customer info is stored in a folder in a separate SharePoint list.  All users can access the other list so you don’t get the access denied error flashing on the screen, but only certain users can access the folder in that list and its contents.  The security is managed at the folder level using SharePoint groups. 


Not applicable

So should I just create 600-700 lists when each row has sensitive information (like salary, for example)?

What works for you may not work for others. I already said that the 'audit'  issue can be easily overcome by adding a column to store the logged in user. And if you are a company that have a 'not so nice' developer, not knowing who writes back what into a Sharepoint list is the least of your problems and definitely not a PowerApps one. 

Kudo Kingpin

Knowing who committed the breach will not help after the fact.  Once the security breach has occurred, it is too late. 


I like the fact that the connectors access data in the context of the currently logged in user. I think it is a good idea and support it.


 I think letting PowerApps access sensitive data using a system account rather than the context of the current user will slow adoption - especially for apps developed for the AppSource Marketplace.


We have to agree to disagree.



Regular Visitor

I honestly don't mind the whole connection thing,  but what I don't understand is that if the connection is used to get information, why not have the ability to add security group / d365 team-like permissions to the connectors?

This way, the connectors as they work now will continue to do so.  But for a more secure approach, connections can be made with various securities attached to them and then shared to appropriate members?

Not applicable

This is something that  put a stop to our app development on Power Apps. The lack of being able to delegate some role based access control to a user and then limit their access to the backend is a necessity.



Helper II

I 10000% agree! This is a HUGE SECURITY FLAW in PowerApps! Allowing users to actually BYPASS the powerapp (including all built in code for security, business logic, etc...) and edit the data DIRECTLY is crazy! Not only that, when you give read/write permission to the user for the excel backend, for example, it actually sends them an EMAIL telling them they have access with a convenient LINK! MICROSOFT - PLEASE PATCH THIS MAJOR SECURITY FLAW. It pretty much makes powerapps alot less useful to companies right now.

Not applicable

totally agree with initial request! Had same issue (and wasted a lot of time) with a Powerapp and Sharepoint. The app should be the one with the permissions to edit the data. All the users need is just access to the app, why do they need access to Sharepoint lists as well? Anyone with even a basic basic knowledge of Sharepoint can just bypass entilrely the app and go directly to the list to edit it. I was so surprised when I published my first app I had built in Powerapps and then it wasn't working for other users. Then I found out I had to share with them all the Sharepoint lists for the app to work. The app I had built was for approval process of sensitive sales information. The record of these approvals is required for Audit purposes and then I realised that anyone that I wanted to be able to use the app could just bypass it and go directly to the lists. Well, that was the end of my foray into Powerapps as no data security and meant I wasn't able to use publish the app for use. Powerapps needs to be able to provide data security in  order to truly come into it's own. At the moment the sales proposition is "here is a product that you can easily customize with little or no coding for a miriad of your front line business needs..... which the users can then bypass and go to the data directly". Please, please, please, this issue needs to be fixed ASAP in order for Powerapps to truly become a viable proposition for business around the world. I mean, as soon as I told my boss that the users could change the data was told to can the project.