{"id":16760,"date":"2021-10-01T09:00:48","date_gmt":"2021-10-01T16:00:48","guid":{"rendered":""},"modified":"2025-06-11T07:52:24","modified_gmt":"2025-06-11T14:52:24","slug":"permissions-support-in-datasourceinfo-and-new-recordinfo-functions-for-dataverse","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/permissions-support-in-datasourceinfo-and-new-recordinfo-functions-for-dataverse\/","title":{"rendered":"Permissions support in DataSourceInfo and (new) RecordInfo functions for Dataverse"},"content":{"rendered":"

We are exited to announce the immediate availability of permissions support for Dataverse with the DataSourceInfo and the new RecordInfo functions in Power Apps.\u00a0 \u00a0These functions open the door for richer Power Apps that check for permissions for a table or record respectively in a canvas app.\u00a0 \u00a0With a permissions check authors can hide and show functionality in the UI based on permissions.<\/p>\n

Dataverse<\/h2>\n

Dataverse has a rich security model that allows for checking permissions at both the table and record level.\u00a0 \u00a0Permission checking capability is part of the connector.\u00a0 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.\u00a0 Dataverse is currently the only data source that supports the permissions feature of these functions.<\/p>\n

DataSourceInfo – table level checking<\/h2>\n

The DataSourceInfo function allows an author to check for create, read, edit, and delete permissions on a data source table.\u00a0 \u00a0An 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\u00a0if the user does not\u00a0have at least those permissions.<\/p>\n

Below is an example of a button “Admins only” that can launch a different screen based on permissions to the table.\u00a0 \u00a0The button is only visible if the user has at least read permissions on the table.<\/p>\n

\"\"<\/p>\n

RecordInfo – record level checking<\/h2>\n

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

\"\"<\/p>\n

Common pattern: table permission versus role checking.<\/h2>\n

Checking for table permissions is a more common, simpler, and more resilient coding pattern than role checking.\u00a0 Permissions granted to role usually result in unique rights to edit a table.\u00a0 \u00a0As 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.\u00a0 Only one check is necessary.\u00a0 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.<\/p>\n

See<\/h2>\n