I have a form where I want to hide certain data fields from users when connected to a SharePoint List. The information is sensitive, so I store that sensitive info in a seperate SharePoint list and then display it in the form along with the nonsensitive info if the user has permission to access it - otherwise it is not displayed. I also create the data in the two lists from powerapps app - pretty cool 🙂
I want to set permissions at the LIST level so users cannot get at the data by going directly at SharePoint...
If i set permissions at the list level for the sensitive data, a user who does not have access to that list sees an ugly red error message saying they dont have access to that datasource - and that is what I want - when they bring up the form. The app performs well and all is good, but that ugly error message is scaring the users.
If I put the list items into a folder within the secure list and break permissions at the folder level, then I can give everyone access to the list of secure info but "wall off" users at the Folder by breaking permissions. The ugly red error message goes away, but there is no way to automagically move the items I create in Powerapps into the folder without a custom workflow ( we can do it but seems sort of silly since we are doing all of this to get around an error message that is confirming we are getting the behavior we want).
To answer your questions,
1. The error message is the default behavior (the error message should be returned by the DataSource side, and there is no ways based on what I know to control how PowerApps handle the response from the DataSource), currently I have no idea to block the error message,
2. No alternative way for PowerApps to work with Lists stored in a folder, to get the App work, PowerApps need to connect to the list directly,
3. Would it work by disabling the DataCard based on user?
Thx for the repy
That link you posted just discusses the visible property of a datacard and does not block the user from accessing it or alleviate the issue I am posting about - still get the error message if that datacard is hidden.
Bottomline - PowerApps needs to understand SharePoint permissions to support branching logic. DataSourceInfo seems like the logical function to use for this, but it does not recognize SharePoint permissions so there is no easy to test if a user has read, edit, or delete permissions in SharePoint .
Would also be great if we could turn off the error message for end users...
I have entered a request for PowerApps to support SharePoint permisisons here. If PowerApps is the replacement for InfoPath then this seems like a core functionality that should be supported in the DataSoureInfo command. Click on the link below and vote yes if you agree.
Check out the new blog for error handling in PowerApps:
No - you will get an error when the app checks to see if the user has access to the list used to store the info ( if they dont have access).
The only way to do this is to give all users access to the list, then create a folder in that list with elevated permissions and use Workflow with impersonation to move or copy the items into that folder and delete the original entry... That is what we do now, but it would not be needed if we could supress the error message saying they did not have access to that SP list...
Given that it's May 2021, I was wondering if there is a way in Power Apps to suppress the error message when a user does not have access to a datasource (and rightly so, because they should not have access). The fields that refer to the data are hidden if the user has no access, but it still shows the error when the screen is displayed.
I've seen the blog post by @lindhorst at New Experimental Feature: Error Handling and Writing Null values to databases | Microsoft Power Apps, but this is a post from 2018. I'd like to know how I can suppress a red error message for a user who does not have access to a data connection - and rightly so.
Learn how to create your own user groups today!
Check out the new Power Platform Community Connections gallery!
Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.