Section Access; LOAD ACCESS, USER.EMAIL, REGION ...; Section Application;

Section Access (data reduction) in Power BI

Section Access reduces data per user with a security table in the script. Power BI uses row-level security roles: DAX filters evaluated with the signed-in user's UPN, usually through a security table. OMIT maps to object-level security.

Partial / different approach Modeling Power BI service

Short answer: Load a security table (UserEmail, Region). Create a role with the filter Geo[Region] IN CALCULATETABLE(VALUES(Security[Region]), Security[UserEmail] = USERPRINCIPALNAME()). Assign groups to the role in the service, and test with View as.

What it does in Qlik

Section Access loads a hidden table of users and access levels. Reduction fields (upper-case names and values) link to the same fields in the data model. When the app opens, it holds only the rows the user may see. * means "all values listed in the section access table", not all values. OMIT hides whole fields. In Qlik Cloud, users are identified with USER.EMAIL (or USERID).

Qlik example

Qlik script
Section Access;
LOAD * INLINE [
ACCESS, USER.EMAIL, REGION
ADMIN, [email protected], *
USER, [email protected], NORTH
USER, [email protected], SOUTH
];
Section Application;

Geo: LOAD Upper(Region) AS REGION, Region FROM [lib://Data/geo.qvd] (qvd);

Power BI equivalent

Role filter on the Geo table (Modeling > Manage roles)

DAX
-- Security: disconnected table with UserEmail, Region
Geo[Region]
    IN CALCULATETABLE (
        VALUES ( Security[Region] ),
        Security[UserEmail] = USERPRINCIPALNAME ()
    )

Everyone sees everything (the * row)

Create a second role with no filter (for example "All regions") and put the admins in it. Members of several roles get the union of what each role allows.

Gotchas and behaviour differences

  • RLS only applies to users with the Viewer role or app/share access. Workspace Admins, Members and Contributors are not restricted.
  • Qlik's * means "all values listed in the table". A role with no filter means all rows. That's a subtle difference if the Qlik table didn't list every region.
  • USERPRINCIPALNAME() returns the UPN, which isn't always the email address. For guest (B2B) users it can return either their home address ([email protected]) or the guest UPN in your tenant (user_partner.com#EXT#@yourtenant.onmicrosoft.com), depending on how the guest was invited and how they sign in. Put a card with USERPRINCIPALNAME() in the report and have a real guest open it before you build the security table. Store both forms if you're unsure.
  • Test as role in the service runs as you, so it won't show what a guest's UPN looks like. Security groups that contain guests may not apply RLS as expected. Add guests to the role directly, or use dynamic RLS through the security table.
  • OMIT (hiding fields) maps to object-level security, which you define in external tools such as Tabular Editor. It is not managed in the same roles screen.
  • Test with Modeling > View as in Desktop and Test as role in the service.

Official documentation

Related pages

Spotted an error or a better pattern? QlikToDax is maintained by a working BI consultant; corrections are welcome via the About page. Last reviewed 2026-10-25.