Semantic model permissions

This article describes semantic model permissions in the Power BI service and how these permissions are acquired by users.

What are the semantic model permissions?

The table below describes the four levels of permission that control access to semantic models in the Power BI service. It also describes the permissions that the semantic model owner has on the semantic model, and other actions that only the semantic model owner can perform.

Permission Description
Read Allows user to access reports and other solutions, such as composite models on Premium/PPU workspaces, that read data from the semantic model.
Allows user to view semantic model settings.
Build Allows user to build new content from the semantic model, as well as find content that uses the semantic model.
Allows user to access reports that access composite models on Power BI Pro workspaces.
Allows user to build composite models.
Allows user to pull the data into Analyze in Excel.
Allows querying using external APIs such as XMLA.
Allows user to see hidden data fields.
Reshare Allows user to grant semantic model access.
Write Allows user to republish the semantic model.
Allows user to backup and restore the semantic model.
Allows user to make changes to the semantic model via XMLA.
Allows user to edit semantic model settings, except data refresh, credentials, and automatic aggregations.
Owner The semantic model owner is not a permission per se, but rather a conceptual role that has all the permissions on a semantic model. The first semantic model owner is the person who created the semantic model, and afterwards the last person to configure the semantic model after taking it over in the semantic model settings.

In addition to the permissions above that can be granted explicitly, a semantic model owner can configure semantic model refresh, credentials, and automatic aggregations.

How are the semantic model permissions acquired?

Permissions acquired implicitly via workspace role

A user's role in a workspace implicitly grants them permissions on the semantic models in the workspace, as described in the following table.

Admin Member Contributor Viewer
Read
Build
Reshare
Write

Note

Permissions inherited via workspace role can only be changed or taken away from a user by changing or removing their role in the workspace. They can't be changed or removed explicitly using the manage permissions page.

Permissions granted explicitly via the manage semantic model permissions page

A user with an Admin or Member role in the workspace can explicitly grant permissions to other users using the manage permissions page.

When users share reports or semantic models, links are created that provide permissions on the semantic model. Users authorized to use those links will be able to access the semantic model. Users with Admin or Member roles in the workspace where a semantic model is located can manage these links on the manage permissions page.

Permissions granted in an app

Users may acquire permissions on a semantic model used in an app if the app owner allows this in the app permissions configuration.

Permissions granted via REST APIs

Semantic model permissions can be set via REST APIs. For more information, see Semantic model permissions in the context of the Power BI REST APIs.

Semantic model permissions and row-level security (RLS)

Row-level security may affect the ability of users with read or build permission on a semantic model to read data from the semantic model.

  • When RLS isn't defined on the semantic model, users with write, read, or build permission on the semantic model can read data from the semantic model.
  • When RLS is defined on the semantic model:
    • Users with only read or build permission on the semantic model will not be able to read data from the semantic model unless they belong to one of its RLS roles.
    • Users with write permission on the semantic model will be able to read data from the semantic model regardless of whether or not they belong to any of its RLS roles.