> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Qlik Cloud

> Connect your Qlik Cloud tenant to Oleria to discover who can reach your analytics: users, groups, tenant and space roles, spaces and their content, app shares, bot users, OAuth clients, client secrets, API keys, and audit activity.

Qlik Cloud is an analytics platform that holds your company's apps, datasets, and other analytics content. Connect your Qlik Cloud tenant to Oleria to see who can administer the tenant, who can see or edit each space and its content, and which bot users, OAuth clients, client secrets, and API keys can reach the tenant API. Oleria connects with a machine-to-machine (M2M) OAuth client and can take remediation actions directly from Oleria.

Each Oleria integration covers one Qlik Cloud tenant. To connect another tenant, add another integration.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Qlik Cloud tenant:

* **Accounts** - every active, provisioned, invited, and disabled user, with name, email, status, creation date, and roles. Invited users are shown as disabled. Users who hold a tenant role with admin level, such as **TenantAdmin**, are marked as administrators.
  * **Last activity** - the time of the user's most recent action in the tenant audit log, so you can find dormant accounts. License changes and Qlik's own background events don't count as the user's activity.
  * **SSO** - shown as configured for every user when the tenant has an active interactive SAML or OIDC identity provider, and as not configured otherwise.
  * **Licenses** - each user's license assignment type, such as full user, professional, or analyzer, from the tenant's license assignments.
* **Non-human identities (NHIs)**:
  * **Bot users** - the user that Qlik creates for each machine-to-machine OAuth client, shown as a service account under the client's name.
  * **OAuth clients** - every OAuth client in the tenant, shown as an application, with the member who created it and a link to the bot user it acts as.
  * **Client secrets** - each OAuth client's secrets, shown as secrets and paired with a credential that shows its status, creation date, and creator. Oleria never reads secret values. A bot user and its OAuth client show their newest secret's creation date as their last credential rotation.
  * **API keys** - shown as personal access tokens, or as API tokens for SCIM keys, each paired with a credential that shows its status (active, expired, or revoked), expiry, and creator. Personal keys are linked to the user who owns them.
* **Groups** - groups synced from your identity provider, custom groups, and the built-in **Everyone** group, with their members and the tenant roles assigned to each group.
* **Roles** - tenant roles, built-in and custom, who holds each, directly or through a group, and what each tenant role allows on spaces, apps, and each other kind of content, read from the role's permissions. Space roles, such as **consumer**, **contributor**, and **producer**, appear as a separate role for each space, such as `consumer (Finance)`, so a space-level grant isn't mistaken for a tenant-wide one.
* **Resources** - shared, managed, and data spaces, and the apps, datasets, and other content items in them. Oleria maps who can reach each space through which space role, directly or through a group, which users and groups an app is shared with directly, and which apps anyone can open through an anonymous link. Space owners and item owners have owner-level access. Apps link to the app in Qlik Cloud. Anyone with an anonymous link appears as one anonymous account with the **Anonymous Accessors** role.
* **Activity** - events from the tenant audit log, such as:

  * user sign-ins and sign-outs, and tokens issued to bot users
  * user, group, role, space, app, and OAuth client creation, changes, and deletion
  * space membership changes
  * API key and client secret creation and deletion
  * license assignments, tenant settings, and identity provider changes
  * app opens and reloads, changes to sheets and other objects in an app, and AI assistant changes
  * app shares

  Each event reads as a sentence, such as "Jane Doe opened app Sales Dashboard", and events on an app link to the app in Qlik Cloud. Sign-ins show whether the user signed in through SSO or with a Qlik Account password. Event types that Qlik Cloud adds later are kept as custom events.

The integration shows the tenant's sign-in methods: **SSO** when the tenant has an active interactive SAML or OIDC identity provider, and Qlik Account email and password otherwise. When the tenant uses a SAML identity provider, Oleria links Qlik Cloud to the app in your identity provider through the SAML signing certificate.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model).

## Prerequisites

* A Qlik Cloud user with the **TenantAdmin** role, to create the OAuth client and assign it a role.
* A dedicated OAuth client for Oleria. Qlik Cloud creates a bot user for it, and that bot user is Oleria's service account in your tenant. Don't share the client with other tools, so its access and audit events belong to Oleria alone.
* The address of your Qlik Cloud tenant, for example `https://your-tenant.us.qlikcloud.com`. Any commercial Qlik Cloud region (`*.qlikcloud.com`) is supported.
* Admin access to the Oleria workspace.

## Required permissions

Qlik Cloud limits an M2M OAuth client's token to both the scopes the client is allowed and the roles of its bot user. Oleria needs both of these:

| Permission | Where to set it | What it covers |
| :- | :- | :- |
| `admin_classic` scope | The OAuth client's allowed scopes | Discovery and every remediation action. It's the only scope Oleria requests. |
| **TenantAdmin** role | The OAuth client's bot user, in **Administration** -> **Users** | Lets the token read and change the whole tenant. |

Oleria checks both when you connect and before every remediation action, and reports which one is missing.

## Create an OAuth client in Qlik Cloud

**1. Create the client**

In Qlik Cloud, go to **Administration** -> **OAuth** and select **Create new**. Choose the **Web** client type, select **Allow Machine-to-Machine (M2M)**, and add the `admin_classic` scope.

**2. Trust the client and copy its credentials**

Set the client's consent method to **Trusted**, then copy the client ID and the client secret.

**3. Give the bot user the TenantAdmin role**

In **Administration** -> **Users**, give the client's bot user the **TenantAdmin** role. Qlik creates the bot user, named after the client, the first time the client requests a token. If the bot user isn't there yet, connect the integration in Oleria first: Oleria requests a token and then reports that the bot user lacks **TenantAdmin**. Assign the role, then select **Authenticate** again.

## Connect Qlik Cloud to Oleria

**1. Open the integration**

Go to your Oleria workspace, select **Integrations**, then select the **Qlik Cloud** tile.

**2. Complete the connection form**

| Field | Notes |
| :- | :- |
| Tenant URL | Required. The address of your tenant, `https://<tenant>.<region>.qlikcloud.com`. Oleria keeps only the address and drops any path. You can't change it after the integration is connected. |
| OAuth Client ID | Required. The client ID of the OAuth client you created. At most 100 characters. |
| OAuth Client Secret | Required. The client secret of the same OAuth client. When you edit the integration, the field is labeled **OAuth Client Secret (optional)**. |

**3. Authenticate**

Select **Authenticate**. Oleria requests a token for the client, checks that Qlik granted it the `admin_classic` scope, and checks that the client's bot user holds **TenantAdmin**. Then it saves the integration.

If Oleria can't reach the tenant, check the tenant URL, client ID, and client secret, and confirm that the client allows M2M and its consent method is **Trusted**. If Oleria reports that the client has no bot user, the client isn't a machine-to-machine client. Create one as described above.

## Verify the integration

Confirm the new instance appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered users, groups, roles, spaces, and NHIs in your Oleria workspace.

On the integration's **Capabilities** tab, **Read users**, **Read groups**, and **Read roles** show as available, each with the `admin_classic` permission.

> [!NOTE]
>
> If you rotate the client secret in Qlik Cloud, edit the integration and enter the new secret. When you edit the integration, leave **OAuth Client Secret (optional)** blank to keep the stored secret. If you change the client ID, enter that client's secret too.

## Remediation actions

Beyond discovery, Oleria can act on Qlik Cloud access to remediate risk. Every action needs the `admin_classic` scope and the **TenantAdmin** role on the bot user. Oleria checks both before an action runs and reports any that's missing.

| Action | What it does | Revert | Qlik Cloud permissions |
| :- | :- | :- | :- |
| Add user to role | Assigns a tenant role to the user, or adds a space role to the user's membership of that space. If the user already holds the role, nothing changes. | Yes - removes what was added. | `admin_classic` |
| Remove user from role | Removes a tenant role the user holds directly, or removes a space role from the user's membership of that space. Removing the last space role removes the user from the space. A tenant role that the user holds through a group is refused with the reason. Remove the user from that group instead. A space role that the user gets only through a group isn't changed, and nothing changes; remove the group's space membership instead. | Yes - adds the role back. | `admin_classic` |
| Disable user / Enable user | Disables or re-enables the user. If the user is already in that state, nothing changes. Invited users can't be disabled, because Qlik Cloud doesn't allow it. | Yes - restores the previous status. | `admin_classic` |
| Revoke access to resource | Spaces: removes the user's direct membership of the space, with all of its space roles. Apps: removes the app's direct share to the user. If the user would still have access afterwards, because they own the space or app, are a member of the app's space, or are in a group that has access, Oleria refuses and names the reason without changing anything. Apps in personal spaces and other kinds of items aren't supported. | Yes - adds the user back to the space with the same roles, or shares the app with the user again. | `admin_classic` |
| Create user | Creates a user with the name, email, and username you give, and adds them to the custom groups you choose. The username becomes the user's Qlik Cloud subject, so it must match the subject your identity provider sends, or the person won't be matched when they sign in. The user is invited unless you choose to activate them. If a user with that username and email already exists, nothing changes. A username that exists with a different email is refused. If adding the user to a group fails, Oleria deletes the new user and reports the action as failed. | Yes - deletes the user Oleria created. | `admin_classic` |
| Delete user | Deletes the user. Bot users are refused: use **Disable NHI** instead. If the user is already deleted, nothing changes. | No - Qlik Cloud can't restore a deleted user. | `admin_classic` |
| Create group | Creates a custom group. If a custom group with that name already exists, nothing changes. A name already used by a group from your identity provider is refused. | Yes - deletes the group if it's still empty and unchanged. | `admin_classic` |
| Revoke anonymous access | Deletes the app's anonymous link shares, so their links stop working. Access through users, groups, and the space stays. If the app has no anonymous link, nothing changes. | No - Qlik Cloud can't restore a deleted link. Share the app again to get a new link. | `admin_classic` |
| Add user to group / Remove user from group | Adds the user to a custom group, or removes the user from one. The user's other groups stay. Groups from your identity provider are refused: change them in your identity provider. If the user is already in that state, nothing changes. | Yes - reverses the change. | `admin_classic` |
| Disable NHI | Bot users and M2M OAuth clients: disables the bot user, so the client can't get new tokens and the tokens it holds stop working. Client secrets: revokes the secret. API keys: revokes the key. | Bot users and OAuth clients: yes - re-enables the bot user. Client secrets and API keys: no - Qlik Cloud deletes or revokes them for good. | `admin_classic` |

Space ownership isn't a space role, so Oleria can't grant or remove the owner role of a space. Change the space owner in Qlik Cloud instead.

Oleria won't remove a role from, disable, delete, remove from a group or a space, or revoke app access of the bot user the connection runs as. It won't disable the OAuth client the connection uses or revoke that client's secrets.

## Known limitations

* **No MFA status or password change date.** Qlik Cloud's APIs don't expose either, so MFA shows as unavailable for users and the last password change stays empty. Qlik Cloud also doesn't expose how each user signs in, so it shows only on their sign-in activity.
* **Last activity comes from the audit log.** Qlik Cloud doesn't record a last sign-in on the user. Oleria uses the time of the user's most recent audit-log event. A user with no event in the last 90 days shows no last activity. OAuth clients and client secrets show no last use.
* **Activity covers the last 90 days.** Oleria reads the audit log that Qlik Cloud keeps for 90 days. It doesn't read archived audit events. Audit events carry no IP address or location.
* **OAuth client creators come from the audit log.** Qlik Cloud doesn't record who created an OAuth client, so Oleria reads it from the client's creation event. Clients created more than 90 days ago show no creator.
* **SSO is detected per tenant.** Oleria shows SSO as configured when the tenant has an active interactive SAML or OIDC identity provider. It doesn't show SSO as required, because Qlik Cloud doesn't expose whether users can also sign in another way.
* **License data depends on your subscription.** If Qlik Cloud doesn't return license assignments for your subscription, such as a capacity-based subscription, license fields show as unavailable.
* **API keys depend on the tenant setting.** If API keys are turned off for the tenant, Qlik Cloud refuses to list them, and Oleria syncs everything else without API keys.
* **Personal spaces aren't collected.** Qlik Cloud doesn't list personal spaces, so their items appear only when the connection's bot user can see them.
* **Anonymous links need Qlik Cloud's anonymous access subscription.** Only tenants with that subscription can share an app through an anonymous link. On other tenants there are no anonymous links to show or remove.
* **Only apps have links.** Qlik Cloud doesn't provide a link for spaces and other items, so only apps, and activity on apps, link to Qlik Cloud.
* **Interactive OAuth clients can't be disabled.** Qlik Cloud has no way to disable an OAuth client, so Oleria disables an M2M client's bot user instead. Interactive clients have no bot user, so **Disable NHI** refuses them. Revoke their client secrets instead. Oleria doesn't show which users have authorized an interactive client.
* **Group actions cover custom groups only.** Groups from your identity provider are managed there, so Oleria refuses to change their members. For a user who is also in identity-provider groups, Oleria checks after each change that those groups are unchanged, and reports the action as failed if they aren't. Oleria restores the user's custom groups. Groups from your identity provider that Qlik Cloud dropped come back the next time the user signs in.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.