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. 

Helper I

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. 



Frequent Visitor

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.





New Member

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.

Frequent Visitor

Hey all,


This video from a Powerapps Commnity call may be of use! Doesn't exactly fix our problem here, but is a good guide to get around it.



Frequent Visitor

Agreed, this is crazy, just wasted time creating an App assuming that surely users wouldn't be able to manipulate the back-end. Very frustrating microsoft, can't use PowerApps now till you fix the problem.

New Member

Tanto potencial que morre no final da homologação.

Após estudo e planeamento miguei para outsystem que já possui proteção embutida.

por favor.. corrijam

Not applicable

How is this issue STILL unaddressed? Even if this many people got it wrong PowerApps' creators should have responded by now...


Advocate II

@Anonymous  Correction:  They fixed it by making the new PowerApps licensing scheme so expensive, nobody can afford to use it anymore anyway.  Problem solved!

Not applicable

And worst, you spend time to deliver a nice app with a strong process and at the end, but at then end, anybody can share his own app...

Can't we add just the two following options ?



Not applicable

Hi all, just an idea as a temporary solution that would work for some of you.

Use two sharepoint lists, one that can only be viewed (Main) and one that can be edited by the user (Secondary)

The app can be connected to both and pull data from the Main one.

When data needs editing, the data is pulled from Main, edited and submitted on Secondary instead.

Now you can have a recursive flow that updates the Main data from the Secondary (grabs secondary, looks up original in Main from title and replaces the Main data with the Secondary data, make sure to delete secondary data after its completed) DO NOT attach the flow to the powerapp, it doesn't need to be ^^ just run it from your user (which will have permissions on both sharepoint lists)

This way you can do all your powerapp blocking to only allow certain data to be edited etc, hope this helps atleast someone 👌