Section Access in Qlik Cloud vs On Premise: Key Differences That Break Migrations

Migrating Section Access to Qlik Cloud is not a lift-and-shift. The load script syntax stays the same, but the user identifiers, group references, and identity model are fundamentally different from on-premise. Teams that copy their Section Access script unchanged and reload in cloud end up locked out entirely or granting full access to everyone. Neither is acceptable in production.

This post documents every difference you need to know before migrating. It assumes you already understand how Section Access works. If you need a foundation first, read the Section Access complete guide before continuing.

Quick Comparison: On Premise vs Qlik Cloud

Why Does USERID Break in Qlik Cloud?

On-premise, the USERID field in your Section Access table matches the Windows/LDAP username in the format DOMAIN\username. A typical access table looks like this:

Section Access;
LOAD * INLINE [
 ACCESS, USERID, REGION
 USER, CORP\jsmith, EMEA
 USER, CORP\mjones, APAC
 ADMIN, CORP\bi_admin, *
];
Section Application;

In Qlik Cloud, there are no domain prefixes. Authentication goes through an Identity Provider, and USERID maps to the subject identifier from that IdP. This is often an opaque string, such as a GUID in Azure AD or a user key in Okta. It is not the plain username your users know.

USER.EMAIL is the reliable identifier in Qlik Cloud. It maps to the email address the user authenticated with via the IdP and is consistent across providers. Most teams migrating to cloud switch to USER.EMAIL as the matching key:

Section Access;
LOAD * INLINE [
 ACCESS, USER.EMAIL, REGION
 USER, jsmith@company.com, EMEA
 USER, mjones@company.com, APAC
 ADMIN, bi.admin@company.com, *
];
Section Application;

Replacing DOMAIN\username values with email addresses is typically the only required change to the access table data for most migrations. The table structure and Section Application logic stay the same.

One important note: matching in Section Access is case-insensitive in both environments. jsmith@company.com and JSMITH@COMPANY.COM will both match. Confirm with your IdP if email casing varies in your directory.

For a broader overview of what changes during a cloud migration, see the Qlik Cloud migration strategy guide.

How Do Identity Providers Change the User Model?

On-premise Qlik Sense authenticates users against Active Directory or LDAP. The username is deterministic and matches what your IT team manages in AD. Usernames are stable and predictable.

In Qlik Cloud, authentication is fully delegated to an external IdP. The exact format of the user identifier depends on which IdP you use and how your tenant is configured:

• Azure AD / Microsoft Entra ID: USERID is typically an object GUID or the UPN, depending on claims mapping
• Okta: USERID is typically the Okta user ID string
• Custom OIDC provider: USERID is whatever the sub claim contains in the ID token

Because the subject claim format varies and can change if you reconfigure your IdP, using USERID directly in Section Access Qlik Cloud deployments is fragile. Email addresses are stable across IdP changes, which is why USER.EMAIL is the safer choice for most organizations.

If you are running into authentication issues after migration, the Qlik Cloud data gateway troubleshooting guide covers common identity and connectivity problems.

Group-Based Access: Custom Groups vs IdP Groups

On-premise, you can create custom groups directly in the QMC and assign users to them. These groups are independent of Active Directory and give you flexible, app-level grouping without needing IT to manage AD group membership. Your Section Access table references these group names in the GROUP field:

Section Access;
LOAD * INLINE [
 ACCESS, USERID, GROUP, REGION
 USER, *, EMEA_SALES, EMEA
 USER, *, APAC_SALES, APAC
 ADMIN, CORP\bi_admin, *, *
];
Section Application;

In Qlik Cloud, groups come from the IdP. When a user authenticates, their group memberships are passed as claims in the authentication token. Qlik Cloud reads those claims and populates the GROUP field in Section Access with the IdP group names. You cannot create free-standing groups in the tenant admin the same way you could in QMC.

What this means for migration: if your on-prem Section Access uses custom QMC groups, you need to either:

1. Create equivalent groups in your IdP (Okta groups, Azure AD security groups) and assign users there, or
2. Switch to user-level access with USER.EMAIL instead of GROUP-based access

As of mid-2025, Qlik improved group handling in cloud tenants. Tenant administrators can now manage group-to-user assignments more directly through the management console, and group syncing from IdP is more reliable than in earlier cloud releases. If you evaluated cloud group support before mid-2025 and found it lacking, it is worth re-evaluating with the current platform.

Streams vs Spaces: What Changes for App Access?

On-premise, streams control which apps users can see and open. Section Access then controls row-level data inside those apps. The two layers work independently but together.

In Qlik Cloud, spaces replace streams for app-level access control. A managed space with appropriate permissions determines who can open an app. Section Access still handles row-level restrictions inside the app once it is opened.

The critical point: you cannot use space permissions as a substitute for Section Access, and you cannot use Section Access as a substitute for space permissions. They operate at different layers:

• Space permissions: controls visibility and access to the app itself (who can open it)
• Section Access: controls which data rows are visible inside the app after it is opened

A common mistake in migrations is assuming that tightening space permissions makes Section Access redundant. It does not. A user with space access but no matching row in the Section Access table will be locked out of the app entirely. A user with a valid Section Access entry but no space access will never reach the app to begin with.

Another practical difference: on-premise, a user with access to a stream sees all apps in that stream unless Section Access restricts the data. In cloud, each space has explicit membership. If you had broad stream access on-prem, you need to explicitly add users or groups to the equivalent managed space in cloud.

For a full walkthrough of deployment and access control in Qlik Cloud, see the Qlik deployment guide.

OMIT Column: Field-Level Restriction

The OMIT column works the same way in both environments. Fields listed in OMIT are excluded from the data model for that user, making them invisible in the app. The syntax and behavior are consistent between on-prem and cloud.

Section Access;
LOAD * INLINE [
 ACCESS, USER.EMAIL, OMIT
 USER, analyst@company.com, SALARY;COST_PRICE
 ADMIN, admin@company.com,
];
Section Application;

No changes needed here when migrating. This is one area where the migration is genuinely seamless.

How Does NULL Handling Work in Qlik Cloud?

NULL values in Section Access act as wildcards in both on-premise and cloud. A NULL in the USERID field means the row applies to all users. A NULL in a data restriction column means the user can see all values in that field.

This is consistent between environments, but it is a common gotcha regardless of platform. An accidental NULL in a restriction column can silently grant full data access to a user who should have limited access. If a reload produces unexpected results after migration, check for NULLs in your access table before anything else.

One scenario where NULLs appear unexpectedly: if you are loading your Section Access table from an external source (SQL table, QVD, Excel file) rather than inline, a JOIN or LOAD that fails to match will produce NULLs. Always validate your access table data, especially after switching from inline values to a data source.

How Do You Test Section Access in Qlik Cloud?

On-premise, you can impersonate a user directly in QMC to verify what they see. This makes testing straightforward and fast.

In Qlik Cloud, impersonation is not available in the same way. The practical approaches are:

• Dedicated test accounts: Create test user accounts in your IdP (e.g., test.emea@company.com, test.apac@company.com) with the appropriate group memberships. Log in as each test user to verify data visibility.
• Separate test tenant: Use a non-production Qlik Cloud tenant for Section Access development and validation before deploying to production. This is the cleanest approach for complex access models.
• Cloud monitoring app: Qlik Cloud’s Operations Monitor (available from the Qlik Cloud catalog) has better visibility into reload logs and user session data than the on-prem equivalent. Use it to audit whether Section Access is applying correctly.

Section Access errors are logged differently in cloud. On-prem, check the Qlik Engine logs in the Qlik installation directory. In cloud, reload errors related to Section Access appear in the app’s reload log, accessible from the app’s hub details panel. The error messages are similar but the location is different.

For a deeper look at security architecture in Qlik Cloud, the Qlik Cloud security best practices guide covers access control layers, audit logging, and compliance considerations.

Script Syntax: What Actually Changes

The Section Access LOAD statement is identical between on-prem and cloud. No syntax changes are required. The Section Access; header, the LOAD * INLINE or external LOAD, the field names (ACCESS, USERID, GROUP, OMIT, USER.EMAIL), and the Section Application; footer all work the same way.

What changes is the data inside the table:

• DOMAIN\username values become email addresses (or IdP subject IDs if you choose that route)
• QMC group names become IdP group names
• Any hardcoded on-prem test accounts need to be replaced with cloud test accounts

If your Section Access table is loaded from a SQL database or QVD rather than inline, the migration is mainly a data migration task: update the user identifier column in that source data to use email addresses instead of domain usernames. The script itself needs no changes beyond that data update.

For reference on the official field definitions and Section Access syntax, see the Qlik Cloud Section Access documentation.

Section Access Migration Checklist

Before migrating Section Access from on-prem to Qlik Cloud:

1. Audit your current USERID values. Export your access table and identify every DOMAIN\username value. Map each to the corresponding email address used in your IdP.
2. Decide on the identifier strategy. USER.EMAIL is recommended for most cases. If your organization has users with multiple email addresses or shared accounts, document the exceptions before proceeding.
3. Audit GROUP values. List every group name referenced in your access table. Confirm each group exists in your IdP with the same name (case-insensitive matching applies). Create any missing IdP groups.
4. Map stream access to space access. For each stream that contains apps with Section Access, create the equivalent managed space in cloud and add the appropriate users or groups.
5. Create test accounts in your IdP. Set up at minimum one test account per access level you want to verify. Test accounts should have the same group memberships as real users in their tier.
6. Run a reload dry run on a test tenant. Before touching your production cloud tenant, deploy the app with updated Section Access to a test tenant and verify with test accounts.
7. Check for NULL values. After the first reload on cloud, export the resolved access table data and scan for unexpected NULLs.
8. Verify OMIT fields. If you use field-level restrictions, log in as a test user in each OMIT tier and confirm the fields are absent from the data model.
9. Check reload logs. After the first production reload, review the app reload log for Section Access warnings or errors before telling users the migration is complete.

If you ran into problems during your migration, the Qlik Cloud migration errors guide covers the most common failure patterns and how to fix them.

Frequently Asked Questions

Does Section Access syntax need to change for Qlik Cloud?

No. The load script syntax is identical between on-prem and cloud. The Section Access; and Section Application; markers, field names, and LOAD structure all work the same way. What changes is the data values in your access table: user identifiers switch from DOMAIN\username to email addresses, and group names switch from QMC custom groups to IdP group names.

Why does using USERID break in Qlik Cloud even when I enter the correct username?

In Qlik Cloud, USERID does not contain the plain username from your directory. It contains the subject identifier (sub claim) from your IdP’s authentication token. This is an opaque string in many IdPs, not the human-readable username. Unless you have explicitly configured your IdP to pass the username as the subject claim, USERID will not match what you expect. Switch to USER.EMAIL instead, which reliably maps to the user’s email address.

Can I still use group-based Section Access in Qlik Cloud?

Yes. The GROUP field works in Qlik Cloud, but groups must come from your IdP rather than from QMC custom groups. When a user authenticates, their IdP group memberships are included in the authentication token, and Qlik Cloud populates the GROUP field with those values. Make sure the group names in your Section Access table exactly match the group names in your IdP (matching is case-insensitive). If you relied on QMC-managed custom groups on-prem, you need to recreate those groups in your IdP before migrating.

What happens if a user has no matching row in the Section Access table in Qlik Cloud?

The behavior is the same as on-prem: the user is denied access to the app entirely. This is by design. Section Access defaults to deny. If you are seeing unexpected lockouts after migration, the most common causes are: USERID format mismatch (using domain username instead of email or IdP subject), group name mismatch between the access table and the IdP, or a case sensitivity issue in the GROUP or USER.EMAIL value.