Row-level security and View as

Row-level security (RLS) limits which rows each viewer of a semantic model gets, so one model can serve several audiences. Use it when different people should see different data in the same reports. Set the rules on the model, turn them on, and check the result with View as before you share a report.

How viewers are treated

While the Row-level security toggle is On, each viewer falls into one case:

• Main group members see every row.
• In Groups mode, a viewer sees the rows that match any of their groups' conditions. Membership in several groups combines with OR: "If a user belongs to multiple groups, their filters are combined with OR."
• In SQL mode, everyone outside the Main group gets the single condition under Everyone else.

While the toggle is Off, the rules are saved but not applied, and every viewer sees all rows.

These rules apply only to the reports built on this semantic model. Access to Warehouse tables is set separately (Warehouse permissions and row-level security).

The rules cover every place the model reads rows: chart results, filter and slicer value lists, downloads, drill views, and the previews inside the model editor. When the rules leave an identity with no rows, the result is empty rather than broken: charts finish with zero rows, the report shows one quiet notice, value lists come back empty, and a download produces no file. When you email a report, each recipient gets it under their own rules, and the form warns about recipients who would see no data (Email subscriptions).

Set up groups

1. Click DataPrism in the sidebar, open the semantic model, and select the Row-level security tab.
2. Under Main group, click Add members and add the people or roles that need every row. Skip this step if nobody does.
3. Make sure Mode is set to Groups, then click Add group.
4. Enter a Group name, choose a Target table, and add Members. Changing the target table resets the condition, so choose the table first.
5. Under Condition, add Rule rows, and Group rows to nest, and join them with AND or OR.
6. Repeat steps 3 to 5 for each audience.

The panel says "No groups yet. Users who are in no group see no rows while row-level security is enabled." until you add the first group. The When to use Groups or SQL popover next to Mode explains when each mode fits.

Use one SQL condition for everyone else

1. Open the Row-level security tab and set Mode to SQL.
2. Under Everyone else, choose the Target table.
3. Write the condition in the editor. Use {user_email:String} where the viewing user's email should be compared. It is filled in for you, and it is the only parameter that is substituted: "Only {user_email:String} is substituted at query time."
4. Turn the toggle On, then click Save.

SQL conditions are refused when they contain a semicolon, a comment or a statement that changes data or structure. Before the save completes, each condition is checked once against its target table; a missing column or a syntax error refuses the save and shows the reason.

Save and apply

• Groups and SQL are two editors for the same rules. Switching only changes the editor, as the footnote says: "Turn On and Save for either mode to apply. Switching this tab only changes the editor."
• Save stays off while the draft has issues. The panel lists what is missing: "Add at least one group.", "Group 2 needs a name.", "Group 2 needs a target table.", "Group 2 needs a condition.", "Choose the table the SQL condition filters.", "Write the SQL condition for everyone else."
• Saving replaces the whole configuration with what you see on screen. Discard reloads the last saved state, and a successful save confirms with the toast "Row-level security saved".

Test with View as

1. Open a report built on the model.
2. In the report header, click View as.
3. Pick a person from the suggestions, which are marked Active, or type an email and click View. A typed address must be valid and match an active user, or it is refused: "Enter a valid email address." or "No active user has this email."
4. A banner reads "Viewing as {email} - charts show what this user is allowed to see", and every chart shows the rows that person would get.
5. Click Exit to return to your own view.

View as lasts for your session only; the popover notes Session only, and the other person sees nothing different. The header action shows the email you are viewing as while it is on. When the model's rules are Off, the same action explains that and offers Enable RLS if you can edit the model.

If the rules give that person no rows, the report shows "Row-level security: no data is available for {email}" (or "for your user" outside View as), with Dismiss. You can dismiss it for that report in this browser. Reports on a model with row-level security On carry an RLS badge next to the title.

What blocks turning it on

• Public links. While any report of the model has a live public link, the panel refuses the change and says "Unpublish first to turn on RLS." A model with row-level security cannot have public links at all, so unpublish them first on Share a report.
• Chart API tokens. While chart API tokens exist on reports of the model, the panel says "Revoke the chart API tokens first to turn on RLS." Turning the rules Off is also refused while tokens limited to a group exist: "Chart API tokens limited to RLS groups are active on this model. Revoke them first to turn off RLS." Revoke them on Export reports and data.

Row-level security and the Model AI

The Model AI can read and explain a model's row-level security and suggest changes, but it does not change the rules itself: a person applies changes in the Row-level security tab. See Model AI.

Who can manage and use the rules

• Managing row-level security needs the Edit DataPrism Semantic Model permission and edit access to the workspace the model lives in. Without it the tab shows "Managing row-level security requires semantic model edit access." See Who can do what in DataPrism.
• The tab also needs the model to have at least one BI table; before that it stays greyed out. See Semantic models and BI tables.
• View as is offered to administrators, to Main-group members while the rules are On, and to people who can edit the model. For everyone else it is not offered.
• The built-in admin role always bypasses row-level security. It appears in the Main group with a lock and cannot be removed.

Questions, answered

Why does a viewer in no group see an empty report?

Because the rules are On and the viewer matches no group, so no rows qualify. They see an empty result rather than an error. If they should see data, add them to a group or to the Main group.

What does a viewer in two groups see?

The rows that match either group's condition. Membership in several groups combines with OR.

How do I filter rows by the viewer's own email?

Use SQL mode and write {user_email:String} in the condition; it is replaced with the viewing user's email at query time. It is the only parameter that is substituted, and a Groups condition cannot use it.

Why does everyone still see every row after I saved my rules?

Check three things. The toggle may still be Off; the panel warns "RLS groups are configured but row-level security is DISABLED - conditions are not applied." The viewers may be Main-group members, who always see every row. Or the model is in SQL mode, where everyone outside the Main group gets the single condition under Everyone else.

Why can I not turn row-level security on?

Public links or chart API tokens still exist on reports of the model. Unpublish the links on Share a report and revoke the tokens on Export reports and data, then turn the rules on. The panel names the reason next to the toggle.

Why is View as not offered to me?

View as needs Main-group membership while the rules are On, or edit access to the semantic model. Ask someone who can edit the model to check the view for you.

Does View as change what the other user sees?

No. It applies to your session only. Charts show the other person's rows until you click Exit.

Why is my SQL condition refused?

Write one condition with no semicolon, no comment and no statement that changes data or structure, and make sure every column it names exists. Each condition is checked against its target table before the save completes; a problem refuses the save and shows the reason.

Do administrators bypass row-level security?

The built-in admin role always bypasses it. It appears in the Main group with a lock and cannot be removed. Holders of any other role follow the rules unless you add them to the Main group.

Do model checks and measure tests respect row-level security?

No. Model checks, data checks and measure tests run without row-level security, so they read every row and a result can describe rows a person would not see. Use View as to check what a person actually gets. See Check, document and trace a model and Measures.

Do viewers see the filter that row-level security adds?

Not in full. In a chart's SQL view, viewers outside the Main group see /* row-level security filter applied */ in place of the added filter; Main-group members and model editors see the whole statement. See Build a report.