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 V


Yes, you could hard code a passcode into both your Power App and into the second flow for a bit more security. However, this is easily circumvented by the resourceful user, because they'll be able to isolate the passcode from the data stream, if it's sent in plaintext. That's precisely why I hashed the passcode and made the passcode itself time-sensitive. The user can't see the code in Power Apps or Power Automate that generates the token, so while they could isolate the token from the data stream, they wouldn't be able to reuse it from another Power App or flow.

Kudo Kingpin

There are two kinds of Flows - Instant Flows and Background Flows - 

Instant Flows are triggered using the PowerApps Connector and you typically add them to the OnSelect of a button in the Power App.  They get called instantly when a user hits the button and you don't need to "share them".  If you have access to the button then you can invoke the instant flow.


Background flows are triggered on a timer job behind the scenes.  They have a trigger like " when an item is added to this Sharepoint list"... Those background flows can be shared.  They can sometimes take up to 5 minutes to run.


I almost ALWAYS use instant flows and call them through a button click or with logic within the Power App or On Success when I submit a form . They are super useful and powerful.


You don't need to hardcode the password, just have a flow call another flow using the method I described in the last post.


If you did want to pass the password, you can do it as a parameter or create a JSON structure and pass the password to the flow from the specific Power App that invokes the instant flow.  That way, if another app invokes the instant flow it wont have the password to pass to the flow - since that password is embedded within the logic (script) of the original Power App - I hope this makes sense!

Helper II

Yes, this all makes sense. Again, thanks to both of you. As I mentioned way above in this thread, I was ecstatic when I heard about PowerApps, and then crestfallen when I learned about implicit sharing. It was a gloomy day, indeed, as I thought I wouldn't be able to use PowerApps after all. Your contributions to this solution saved me.

Helper III

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.

Helper III

Any update on this one @CWesener ?

Power Apps
Status changed to: 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.