We are exited to announce the immediate availability of permissions support for Dataverse with the DataSourceInfo and the new RecordInfo functions in Power Apps.   These functions open the door for richer Power Apps that check for permissions for a table or record respectively in a canvas app.   With a permissions check authors can hide and show functionality in the UI based on permissions.

Dataverse

Dataverse has a rich security model that allows for checking permissions at both the table and record level.   Permission checking capability is part of the connector.  So, note that even though a data source might natively support similar kinds of permission checking as Dataverse, the Power Apps connector for the data source must expose this functionality in order for a Power Apps author to use it.  Dataverse is currently the only data source that supports the permissions feature of these functions.

DataSourceInfo – table level checking

The DataSourceInfo function allows an author to check for create, read, edit, and delete permissions on a data source table.   An author can use this function to check for permissions and then reveal more functionality if the correct permissions for the user are present. For example, an author might check for the lowest permissions possible (e.g., read) and then show/hide a button that launches a different screen if the user does not have at least those permissions.

Below is an example of a button “Admins only” that can launch a different screen based on permissions to the table.   The button is only visible if the user has at least read permissions on the table.

RecordInfo – record level checking

The new RecordInfo function allows a Power Apps author to check for record level permissions.   Like DataSourceInfo an author can use this function to check for  read, edit, and delete permissions.  As above, an author can choose to hide or show capabilities based on these permissions.  In the example below, the ‘Delete’ button is visible when the user has permissions to delete on the currently selected record.  This example is shown with a gallery, but could also be on a form.

Common pattern: table permission versus role checking.

Checking for table permissions is a more common, simpler, and more resilient coding pattern than role checking.  Permissions granted to role usually result in unique rights to edit a table.   As more roles are created in a system over time, an application is more resilient to change if it uses a simple table permissions check because permissions from various roles merge at the table level.  Only one check is necessary.  If two different roles both grant rights to a given table, then a simple check of table permissions works without having to update an app to check for additional roles.

See

• DataSourceInfo function.
• RecordInfo function