# Security (RLS)

{% embed url="<https://www.youtube.com/watch?v=xuLr4iWR378>" %}

RLS (Row-Level Security) in Power BI can be used to restrict data access for specific users. Filters restrict data access at the row level, and you can define filters in roles.

RLS allows you to:

* Define data loading filters based on the user viewing the report
* Create multiple data filterings in a single report
* Restriction by user profile
* Restriction by role (job title/department)

One of the advantages of RLS is having a single report and distributing it to multiple users or clients, without having to create a report with filtered data for each user profile, reducing the maintenance of these reports, since a single report would filter the results displayed according to the person viewing it.

In Power Embedded, we support both RLS (Row-Level Security) and OLS (Object-Level Security).

{% hint style="warning" %}
RLS/OLS is configured ONLY in Power Embedded, no longer in the Power BI service.

If it is necessary for some people to continue accessing the report in the Power BI service, you will need to configure it in Power BI as well.
{% endhint %}

Below is some information to help with understanding.

<div align="left"><figure><img src="/files/lW85Sy8WkL4tzxsQq9Gn" alt=""><figcaption></figcaption></figure></div>

When the report has one or more RLS rules, it is mandatory to associate it with the user viewing the report, either using static or dynamic RLS, otherwise they will not be able to view the reports, and a message like this will be displayed:

<div align="left"><figure><img src="/files/FV6mZ28QbNnlboMo5u1T" alt=""><figcaption></figcaption></figure></div>

{% hint style="warning" %}
Unlike the Power BI service, where administrator users are not affected by RLS, in Power Embedded, ALL users are affected by RLS.

If an administrator user is not in any security rule, they will receive the error message above. If this user needs to view all data, create a security rule without any filter and associate the user with that security rule.
{% endhint %}

### How to manage security rules in Power Embedded

To associate a user with an RLS or OLS rule, you have 3 ways to configure this:

1. On the [Reports](https://admin.powerembedded.com.br/Reports) screen, search for the report you want to manage the RLS rules for, click the **Actions** button, and then click the **Security** item.\
   \
   If the report has RLS and this button is not appearing, go to the [**Datasets**](https://admin.powerembedded.com.br/Datasets) page and click the **Reload** button.\
   \\

   <figure><img src="/files/R93pU1sKlAi87lfX4mba" alt=""><figcaption></figcaption></figure>
2. On the [Reports](https://admin.powerembedded.com.br/Reports) page, search for the report you want to manage the RLS rules for, click the **Actions** button, and then click the **Edit** item.\
   \
   You should see a yellow button called **Edit RLS.** If the report has RLS and this button is not appearing, go to the [**Datasets**](https://admin.powerembedded.com.br/Datasets) page and click the **Reload** button\\

   <figure><img src="/files/EwZJeW727DIpJsCpI81S" alt=""><figcaption></figcaption></figure>
3. On the [**Datasets**](https://admin.powerembedded.com.br/Datasets) page, search for the dataset you want to manage the RLS rules for, click the **Actions** button, and then click the **Security** item. \\

   <figure><img src="/files/p0vM1MvushUyKKRBXoEu" alt=""><figcaption></figcaption></figure>

### **Static Security**

For companies that need or would like to create multiple security rules and associate users with the rules, without the need to have a table in the model with users and permissions, there is static security, which is simpler to configure, but has worse performance and is harder to manage permissions.

In this format, you will see the list of roles that exist in the model and can associate users or groups that will be filtered by that rule, by clicking the actions button.

<figure><img src="/files/FFhQjpsAYdgYyApbC8eg" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/9NY46KSTmxcDUrz0C77H" alt=""><figcaption></figcaption></figure>

Here is a screenshot of the rules created in Power BI Desktop. There are two rules created: 'Foods' and 'Beverages'. This means that if a user is assigned to the Foods rule, they can only view data related to foods.

<figure><img src="/files/vuW7V3bWpnUG9pqS1DC7" alt=""><figcaption></figcaption></figure>

After publishing the report and accessing "Actions" > "Security", Power Embedded automatically identifies the created rules and loads the list with these rules.

You can then assign these rules to users as needed.

{% hint style="warning" %}
If the list of security rules is not being displayed on the security screen, even after clicking the "Reload roles list" button, it is probably because the report's workspace is in a PRO capacity instead of a dedicated capacity (Fabric, Power BI Embedded, or Power BI Premium).
{% endhint %}

When user "marcos" accesses the report, they will only see information related to foods.

<figure><img src="/files/gD6LFRnPD1cdzm0rosjB" alt=""><figcaption></figcaption></figure>

### **Dynamic Security**

With Dynamic Security, you can define one or more roles and they will be automatically applied to all users who access the report. This is the best practice recommendation for better rule management and performance.

In this format, the role/function created in Power BI Desktop will receive the email of the user accessing the report (using the `USERNAME()` or `USERPRINCIPALNAME()` functions) and will be responsible for performing filters using this email, based on the created rules.

<figure><img src="/files/TZLzPgygGyYBdNKv2nlc" alt=""><figcaption></figcaption></figure>

In this approach to automatically applying filters per user, it is necessary to maintain in your model a table with users and permissions according to the RLS or OLS rule.

The table below illustrates a model containing the email information of the managers of a given report.

<div align="left"><figure><img src="/files/nF2SEfEfGwxp21gV2miI" alt=""><figcaption></figcaption></figure></div>

Relationship between the tables, meaning your table will be linked to a fact table that contains the information.

<div align="left"><figure><img src="/files/lO90UQRNZz5cfJCQ16gH" alt=""><figcaption></figcaption></figure></div>

After publishing this report, the rule becomes visible in the portal — simply select it and the rule will be applied. Unlike static security, here you do not assign a user to the rule; you simply click on the rule you want to apply.

<figure><img src="/files/MDitNnxIeNI1qwVDfLsP" alt=""><figcaption></figcaption></figure>

Report without the existing rule:

<figure><img src="/files/PI4nKn4mbvOU1RJhM4fq" alt=""><figcaption></figcaption></figure>

Report with an existing RLS rule in the model using dynamic RLS:

<figure><img src="/files/mIB97Jh3RM9hUVDMDDNh" alt=""><figcaption></figcaption></figure>

The RLS rule is applied using the `UserPrincipalName()` function to identify which user is logged in and perform the filter on other tables as well, meaning the user can only view information relevant to them.

### Priority of static and dynamic RLS

To correctly configure RLS rules in some scenarios, it may be necessary to use both static and dynamic RLS at the same time.

How Power Embedded prioritizes these rules:

1. Checks if the user viewing the report is associated with any static RLS rule. If so, sends that rule and ends the validation.
2. Checks if the user viewing the report belongs to any group that is associated with any static RLS rule. If so, sends that rule and ends the validation.
3. Checks if any dynamic RLS rule is selected. If so, sends that rule and ends the validation.
4. None of the previous conditions were met, so no RLS rule will be sent and there will probably be an RLS error when trying to open the report.

### RLS with DirectQuery in Power BI

If you encounter the error below when trying to access the report, it is very likely that the table containing the RLS rule is using the DirectQuery connection.

<figure><img src="/files/qt2gWaZe02pffYYCl3nd" alt=""><figcaption></figcaption></figure>

DirectQuery is widely used to access real-time data. However, it is important to note that Row-Level Security (RLS) rules do not directly apply to tables connected via Direct Query in Power BI.

This happens because the configuration of these rules, when using DirectQuery, must be done at the database level, not in Power BI.

Therefore, it is important to change the table connection to Import or Dual mode, if it is necessary to apply these rules.

To change the table connection, follow the steps below:

1. Open Power BI Desktop.
2. Go to **"Model View"**.
3. Select the table that **has RLS rules and is connected via DirectQuery**.
4. Access the **"Advanced"** menu, as shown in the image.
5. Change the storage mode to **"Import" or "Dual".**

<figure><img src="/files/7aoWkC3xZt0yCpZEjHmX" alt=""><figcaption></figcaption></figure>

After following the previous steps, a warning like the one shown in the image will appear on the screen. Just click "OK" and proceed. After completing this process, simply publish the report again.

<div align="left"><figure><img src="/files/4FRzDbDz5SJOzC5pDChk" alt=""><figcaption></figcaption></figure></div>

You will now be able to see your information.

## Limitations when using RLS in Embedded reports

When using **RLS (Row-Level Security)** in embedded reports, it is important to consider some limitations defined by the **Embed Token** generation API.

According to Microsoft's official documentation, the **roles** parameter, used during embed token generation, is responsible for informing which RLS roles should be applied to the user accessing the report.

According to the documentation:

* An identity can contain **up to 50 RLS roles**
* A role name can contain any character, **except `,`**
* A role name **cannot exceed 50 characters**

This means that when embedding reports that use RLS, the **role name defined in the model cannot have more than 50 characters**, as this value is sent at the moment of access token generation.\
The 50-character limit applies **only to the role name**, not to the logic or expression used in the security rule.

Therefore, when creating security roles in **Power BI Desktop**, it is recommended to keep names short and objective, ensuring the length **does not exceed 50 characters**, to avoid issues when generating the embed token.

Microsoft's official documentation: [Embed Token - Permissions](https://learn.microsoft.com/en-us/rest/api/power-bi/embed-token/generate-token#permissions)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.powerembedded.com.br/en/administration-portal/reports/security-rls.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.