Skip to content

Row-level security

Row-level security limits the rows each person sees in reports. You create security roles on a data model. Each role has a filter for one or more tables, and a list of members. When a member opens a report, every visual shows only the rows that pass the filters of their roles.

Row-level security is on every plan.

  • You need Build permission on the data model to create or change security roles. Without it you see “View only; Build permission is needed to edit security roles.”
  • The people you add as members must be members of your organization. See Members and roles.
  • People with Build permission on the data model are not filtered. They see all rows.
  • Everyone else gets the roles they belong to, directly or through a group.
  • A person in several roles sees the rows that at least one of their roles allows. If one of their roles does not filter a table, they see all rows of that table.
  • When the data model has no role, everyone who can open the report sees all rows.
  • When the data model has at least one role, a viewer in no role sees no data.
  1. Open the data model.
  2. Click the Row-level security tab.
  3. Click Create security role. A role named New role appears in the list.
  4. Enter the Security role name (1 to 128 characters, unique in the data model).
  5. Optional: enter a Description.
  6. Click Save.
  1. Select the role.
  2. Under Add a filter for a table, pick a table.
  3. Type the Filter expression (functions).
  4. Click Check. You see “The expression is valid” when it is correct.
  5. Click Save.

To remove a filter, click Remove filter, then Save.

A filter is a true/false condition on the columns of its own table. A row is shown when the condition is true.

You can use:

  • columns of the same table, written as Table[Column],
  • text in double quotes, numbers, and DATE(year, month, day),
  • comparisons: =, <>, <, <=, >, >=, and IN { ... },
  • && (and), || (or),
  • the functions NOT, ISBLANK, BLANK, TRUE, FALSE, USERPRINCIPALNAME and USERNAME.

USERPRINCIPALNAME() and USERNAME() return the verified e-mail address of the person who views the report. The comparison ignores upper and lower case and spaces at the ends. A person without a verified e-mail sees no rows of a table whose filter uses these functions.

You cannot use variables, aggregates, measures, or columns of other tables. Filters reach other tables through relationships: a filter on the table on the one side also filters the related table on the many side. On the many side, a row whose key is blank or has no match is hidden. See Relationships.

Examples:

Sales[Region] = "North"
Sales[Region] IN { "North", "South" }
Employees[Email] = USERPRINCIPALNAME()
Orders[OrderDate] >= DATE(2026, 1, 1) && NOT(ISBLANK(Orders[CustomerId]))
  1. Select the role.
  2. Under Test as this role, click Run test.

Fresco BI counts the rows of each table with the role applied on the current draft. Only you see the result.

View as shows a published report exactly as another person or a security role sees it, so you can check that permissions are right. It is read only: you cannot edit, share or export while you view as someone else, and the use is written to the audit log.

Who may use it:

  • Organization Owners and Admins: view as any member of the organization.
  • Workspace Admins: view as the people who have access to that workspace.
  • Editors and everyone else cannot use View as.

To use it:

  1. Open a published report in the viewer and click View as.
  2. Choose Other user and pick a person with Search by name or e-mail, or choose Security roles and tick the roles. In a My workspace only roles are offered, never other users.
  3. Click View. A banner shows Viewing as the person or roles. Click Exit to stop.

When you view as a person, the report shows the pages and the rows that person gets: their security roles (direct and through groups) and their page permissions. A person who cannot open the report is told so. The banner also opens Effective permissions: the person’s org role and workspace role, each report, Data Table and data model they can reach as Read or Build, their Applications and their row-level security roles. Each line says where the right comes from, for example Workspace role: Editor, Shared: Read, Security role: Sales North or through group a group name.

You also need Build on the data model: View as never shows more than both of you can see. On the data model security page, Test as a user counts each table’s rows as a chosen person sees them.

Security roles take effect when you publish the data model.

  1. Click Save draft.
  2. Click Publish.

See Data models. If the roles were never published, you see “Security roles are not published yet”.

You can add members only to a role that is published.

  1. Select the role.
  2. Under Members, open Users and groups.
  3. Pick the people and groups of your organization.
  4. Click Save members.

Member changes apply at once. You do not need to publish again.

Organization Owners and Admins create groups under User groups in the workspace sidebar. See Members and roles.

  1. Select the role.
  2. Click Delete.
  3. Confirm.

Viewers in no role see no data. Check that each viewer is still in another role.

Item Limit
Security roles in a data model 100
Table filters in a role 200
Members in a role 5,000
Roles with different filters that apply to one person on one data model 16
Filter expression 4,000 characters
Role name 128 characters
Description 2,000 characters

Does row-level security apply to Explore? If row-level security applies to you on a Data Table, you cannot use that Data Table in Explore. Explore tables do not inherit security roles. See Explore.

Can I filter on a measure? No. A filter uses only the columns of its own table.