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, ADMIN@CORP.COM, *
USER, ANNA@CORP.COM, NORTH
USER, BOB@CORP.COM, 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. For guest (B2B) users, check what it returns before going live.
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

Managing data security with Section Access (Qlik Help)
Row-level security (RLS) with Power BI (Microsoft Learn)
USERPRINCIPALNAME function (DAX) (Microsoft Learn)
Object-level security (OLS) (Microsoft Learn)

SET vSales = Sum(Sales); LET vToday = Today(); Variables (SET, LET and $-expansion) Qlik variables hold expressions, values and settings, and are expanded as text. Power BI splits these roles: measures for reusable logic, Power Query parameters for load settings, what-if and field parameters for user input, calculation groups for logic applied to many measures, and VAR inside DAX. Partial / different approach $Syn tables (automatic) Synthetic keys and associative linking Qlik links tables automatically on every field with the same name and builds synthetic keys when they share several fields. Power BI never links by name. Relationships are explicit, use a single column and have a direction, so migrations usually remodel to a star schema. No 1:1 equivalent LOAD * INLINE [ ... ]; Inline load (hard-coded tables) Inline loads define small tables in the script. In Power BI, use Enter data in the ribbon, a #table expression in Power Query, or DATATABLE in DAX. Direct equivalent

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.