Object permissions refer to permissions that are assigned to individual objects within the Power BI Service, such as dashboards, reports, and datasets. Unlike workspace permissions, which assign access to all of the objects within the workspace, object permissions only assign permissions to an individual object. However, there is a hierarchy to these object permissions so that assigning permissions at one level of this hierarchy will, by default, assign certain permissions to related objects lower in the hierarchy.

To understand how object permissions work, consider that the hierarchy for dashboards, reports, and datasets is as follows:

• Dashboards
• Reports
• Datasets

This is a logical hierarchy as dashboards are built from reports and reports rely upon datasets. This means that when a report is shared, permissions are assigned for the report but are also assigned to the related dataset for that report. However, no permissions are assigned to any dashboards. The hierarchical flow of permissions is required since dashboards, reports, and datasets, are all separate, yet related objects that are dependent on objects lower in the hierarchy. For example, assigning a user permission to view a report would be useless without that user also being able to have permission to read the underlying dataset for that report. Similarly, assigning permissions when sharing a dashboard assigns the corresponding permissions for any related reports and datasets.

There are five permissions that can be assigned to objects. However, things can get a bit confusing because objects inherit workspace-level permissions and these workspace permissions will read somewhat differently depending on whether you are in the sharing interface or the Manage Permissions interface. These permissions are as follows:

• Owner
• Read
• Reshare
• Build
• Edit

Because object permissions can be confusing, the best way to demonstrate how the permissions work is through an example. In this example, the following workspace level permissions have been assigned:

• Gregory Deckler – Admin
• Kenneth – Member
• David – Contributor
• Mark – Viewer