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: Under Review
Level: Powered On

One theoritical work-around we came up with, but we haven't implemented yet, is having a "service account" for Flow, and passing data back and forth between the process and the service account.  We probably would use the built-in API services in Flow.  So if I was querying the database, I would trigger my process flow, then send over the query/parameters to the service account's flow via REST, which would have full access using CDS, and then return the data via a REST call back to the process flow.  I say theortical because there's so many points of failure that we haven't justified trying to do it yet.  I'm guessing performance would take a big hit as well. 



Level: Powered On

Yes, we've used a service account and assigned it a P2 license so it has the least Flow performance restrictions and can access on premise data sources. It's triggered by a new entry or change in a SharePoint List which then usually returns data to the same or another SP list.


You can't directly use that Flow from PowerApps as the Flow runs under the (standard) user (of the PowerApp) calling the Flow and not the service account, even if you created the Flow and / or PowerApp under the service account.


FYI, There's a noticeable performance hit using an On-Prem gateway, but it's acceptable.





Level: Power Up

I agree that this needs to be addressed, 

In SharePoint you can specificly set item level permissions and that goes for the same with CDS, however other data sources that may not have the capability are in the largest amount of danger. I think PowerApps should 'mimic' the access in a way that if a user is using the PowerApp, they can integrate with the data with the correct filtering in the app. But as soon as the user locates the data source from outside of the PowerApp they get a permissions blocker.

I like your idea about the app having permissions to do so and not the user, almost acting like an Azure app registration. Would be great if this could be implemented into PowerApps.