When you use a table in Dataverse that a user doesn’t have access to you might get these error messsages:
You don’t have access to view this data. Server Response <Tablename> failed.
The message is clear, the user hasn’t been given access to a table that the app needs to read.
Now you could create a user role with some permissions on the table and the error message will go away. But what if, the user shouldn’t have access to this table and you want the app to behave differently for different types of users.
You could end up with many apps different apps, or you could handle this using the DatasourceInfo function.
In my case I’ve got a gallery that displays my fruit from my table. Using the following line, I can check if the user has read access to the table.
If(DataSourceInfo(Fruits,DataSourceInfo.ReadPermission), Fruits) Now when the user doesn't have access to the table no error will be thrown.
Whereas DatasourceInfo works on the full table, sometimes you might want to use similar tricks on a record by record basis.
Potentially, you could accomplish the delete button using somethign like:
However, you might sometimes have different permissions configured at a record level.
This is where the RecordInfo Function comes in and something like this on the Visibility property would then work.
Quite often you will find that delete permissions are set at a table level but it is not uncommon to have edit permissions set at a record level. That way you could change the Edit button into a View button like this:
If(RecordInfo(ThisItem, RecordInfo.EditPermission),”Edit”, “View”)
I’ve seen quite a few apps that have their own role based security baked into the app, but if you can use RecordInfo and DatasourceInfo instead then you can take all that security complexity work away from your app and place it where it belongs, in your data model.
One limitation, however, the two functions described in this post, only work with Dataverse. Hopefully this will support SharePoint lists as well one day.
You could also use this to check if a developer or another user is logged in, by checking access on the solutions table. Then you could hide all those little debug options that you may add as a developer.