Control access to datamarts

This article describes access control to datamarts, including row level security, rules in Power BI Desktop, and how datamarts might become inaccessible or unavailable.

Workspace roles

Assigning users to the various workspace roles provides the following capabilities with respect to Datamarts:

Workspace role	Description
Admin	Grants the user permissions to ingest data through a dataflow, write SQL and visual queries, and update the model or semantic model (create relationships, create measures etc.)
Member	Grants the user permissions to ingest data through a dataflow, write SQL and visual queries, and update the model or semantic model (create relationships, create measures etc.)
Contributor	Grants the user permissions to ingest data through a dataflow, write SQL and visual queries, and update the model or semantic model (create relationships, create measures etc.)
Viewer	Grants the user permissions to write SQL and visual queries and access the “Model view” in read-only mode. For more information, see Viewer restrictions.

Viewer restrictions

The Viewer role is a more limited role in comparison with the other workspace roles. In addition to fewer SQL permissions given to viewers, there are more actions they are restricted from performing.

Feature	Limitation
Settings	Viewers have read-only access, so they cannot rename datamart, add description, or change sensitivity label.
Model view	Viewers have read-only mode on the Model view.
Run queries	Viewers do not have full DML/DDL capabilities unless granted specifically. Viewers can read data using SELECT statement in SQL query editor and use all tools in the toolbar in the Visual query editor. Viewers can also read data from Power BI Desktop and other SQL client tools.
Analyze in Excel	Viewers do not have permission to Analyze in Excel.
Manually update semantic model	Viewers cannot manually update the default semantic model to which the datamart is connected.
New measure	Viewers do not have permission to create measures.
Lineage view	Viewers do not have access to reading the lineage view chart.
Share/Manage permissions	Viewers do not have permission to share datamarts with others.
Create a report	Viewers do not have access to create content within the workspace and hence cannot build reports on top of the datamart.

Row level security

Row-level security (RLS) can be used to restrict data access for specified users to a datamart. Filters restrict data access at the row level, and you can define filters within roles. In the Power BI service, members of a workspace have access to datamarts in the workspace, and RLS doesn't restrict such data access.

You can configure RLS for datamarts in the Datamart editor. The configured RLS on datamarts automatically gets applied to downstream items, including the auto-generated semantic models and reports.

Note

Datamarts use the enhanced row-level security editor, which means that not all row-level security filters supported in Power BI can be defined. Limitations include expressions that today can only be defined using DAX including dynamic rules such as USERNAME() or USERPRINCIPALNAME(). To define roles using these filters switch to use the DAX editor.

Define Row Level Security (RLS) roles and rules for Datamarts

To define RLS roles, take the following steps:

1. Open your datamart and select Manage Roles from the ribbon.

2. Create new RLS roles using the Row security settings window. You can define a combination of filters on tables and select Save to save the role.

3. Once the role is saved, select Assign to add users to the role. Once assigned, select Save to save the role assignments and close the RLS settings modal.

To validate the roles created, take the following steps:

1. Select the View as button from the ribbon.

2. Select the role to be validated by selecting the check box for the role, then select OK.

3. The data view shows the access that the selected role has.

To revert to your access, select the View as button on the ribbon again, and select None.

How datamarts become unavailable

A datamart can get marked as an unavailable datamart when one of the following situations occurs.

Situation 1: When a Premium workspace is changed from Premium to non-premium, all datamarts in that workspace become unavailable. The Datamart editor becomes unavailable and downstream usage of the datamart and auto-generated semantic models is blocked. Users or administrators must upgrade the workspace to its original Premium capacity to restore datamarts.

Situation 2: When dataflow updates a datamart and associated semantic model, but due to a system lock the datamart or semantic model update is pending, the datamart becomes unavailable. The Datamart editor isn't accessible when a datamart goes into unavailable state. The try again action, shown in the following image, enables users to trigger synchronization between dataflow, datamart and semantic model. It may take a few minutes to complete the requested action but downstream consumption can be continued.

Situation 3: When a Premium workspace is migrated to another Premium capacity in a different region, the datamart will become unavailable with the error: "Unable to open the datamart because the workspace region has changed. To open the datamart, reconnect the workspace to the region connected when the datamart was created." This behavior is by design since the region where the datamarts were created must be the region where the workspace resides, and migrations are not supported.

Related content

This article provided information about controlling access to datamarts.

The following articles provide more information about datamarts and Power BI:

• Introduction to datamarts
• Understand datamarts
• Get started with datamarts
• Analyzing datamarts
• Create reports with datamarts
• Datamart administration

For more information about dataflows and transforming data, see the following articles:

• Introduction to dataflows and self-service data prep
• Tutorial: Shape and combine data in Power BI Desktop