Overview

Qlik Cloud provides several complementary mechanisms for controlling access to resources and capabilities. These combine to determine what an individual user - or an integration acting on behalf of a user - can see and do.

Think of access control in tiers:

  1. Baseline permissions
  2. OAuth client scopes (for integrations)
  3. Content-level access

Baseline permissions: Tenant-wide

Every user in a tenant begins with a baseline set of permissions that apply across the entire tenant:

  1. Default user profile (“User defaults”)
    • All users automatically inherit any scopes assigned here.
    • Customized by a tenant administrator, using scopes enabled for user default.
    • In the UI these appear as permissions.
    • Example: grant all users the ability to create API keys.
  2. System roles (default roles)
    • Built-in roles such as TenantAdmin, SharedSpaceCreator, or Steward.
    • Each role maps to a bundle of scopes which cannot be customized.
    • Role must be assigned to a user or group of users.
    • Example: assigning a user the TenantAdmin role grants nearly complete access to administrative functions on the tenant.
  3. Custom roles
    • Created by tenant administrators, using the scopes enabled for custom roles.
    • In the UI these appear as permissions.
    • Role must be assigned to a user or group of users.
    • Example: Defining specific task-oriented roles such as giving certain users the ability to manage AI assistants across the tenant.

Together, user defaults, system roles, and custom roles define the tenant-wide baseline for each user.

OAuth client scopes (integration filtering)

When a user accesses Qlik Cloud through an OAuth integration:

  • The OAuth client has its own set of granted scopes.
  • The client’s scopes act as a filter: the user only has the intersection of their own permissions and the scopes assigned to the OAuth client.

This prevents an integration with limited scopes from accidentally gaining elevated privileges, even if the user themselves is an administrator.

Special cases:

  • user_default: resolves to a dynamic set of all user scopes.
  • admin_classic: resolves to a dynamic set of administrator scopes.

Learn more about OAuth and requesting scopes.

Content-level access

Above the baseline tenant-wide permissions, content access is governed by:

  1. Space roles
    • Spaces are the primary containers for apps, data, automations, and other assets.
    • Roles such as Consumer, Contributor, or Operator determine what a user can do inside a space.
    • Example: A user may be a Consumer in the Finance space and a Contributor in the Marketing space.
    • Learn more about Working in spaces on Qlik Help.
  2. Fine-grained access control

How it all fits together

A user’s effective permissions are determined by:

  • Default user profile, plus any roles assigned (default or custom).
  • Filtered by OAuth client scopes when accessed through an integration.
  • Combined with space roles and fine-grained sharing to allow or restrict access to content.

Users assigned administrative roles usually have broad permissions, and may be able to list or access content across spaces.

Regular users typically rely on space roles for their access, and may have only minimal tenant-wide permissions.

Access control enforcement

In Qlik Cloud, some resources reference metadata from other resources, which defines the behaviour of the consuming resource. This design enables flexible collaborative workflows where you can separate data governance roles from development roles, but it requires understanding how access control applies at different stages. For example:

  • A Qlik Analytics application load script or Data Flow may reference tables or columns from a data connection, which defines what data is loaded into the resulting Analytics app or data assets.
  • An Automation may reference schemas, fields, or objects accessed using an automation connection, which are used to define the way the workflow runs. In these cases, the source resource provides metadata (such as table names or column names), while the consuming resource stores and uses that metadata.

Design time vs execution time enforcement

Qlik Cloud enforces access control at execution time, not at design (reference) time.

  • Design time (reference time): Access to source resources is not validated when metadata is referenced. Once metadata is embedded into another resource, it is governed by the access control of the consuming resource, not the source resource.
  • Execution time: Access control to the source resource is enforced when the consuming resource is executed (for example, when a script reload runs).

Example scenario

  1. A user edits a Analytics application load script and references a column from a data source accessed via a data connection they have access to.
  2. A second user, with access to the Analytics application, but not to the data connection used by the first user to create the app can still edit the load script, because access is controlled by permissions on the script itself.
  3. When the second user attempts to execute the script, it fails, because access to the data connection is enforced at execution time.

To prevent execution failures caused by insufficient access to consumed resources:

  • Grant the executing user access to all source resources referenced by the executable resource, or
  • Review permissions on the consuming resource to ensure only users with access to all dependencies can edit or execute it.

Security implications

Source resources do not inherit the access control of the consuming resource. Execution always runs with the permissions of the executing user, not the creator, with access control being evaluated independently against both the source and consuming resource for the executing user.

Guidance

When using executable resources created by others, review which resources are consumed, especially when those resources are sensitive and your permissions differ from the creator’s.

When assigning scopes, space permissions, and execution rights, consider that:

  • Metadata may reference resources the author no longer has access to.
  • Execution uses the permissions of the current user, not the creator. This flexibility enables collaborative workflows and separate governance models, but it requires deliberate permission management to avoid unexpected execution failures or access issues.

Where to go next

Learn:

Was this page helpful?