Platform operations overview

For software companies interested in embedding analytics into their SaaS solutions, they want the analytics platform to provide onboarding capabilities that can be integrated into their own onboarding flows so that the customer receives the full platform experience from the point of purchase.

Qlik Cloud has been built with a set of APIs that allow provisioning, configuration, and hydration of Qlik Cloud tenants to serve automated deployment pipelines alongside your software and customer lifecycles.

The tutorials in this section provide information on how to leverage Qlik Cloud to support your applications via embedded analytics, as well as covering important considerations for your deployments. The topics and terminology below will be explored in more detail as you progress through the tutorials.

Note: Platform Operations also support Enterprise and internal use cases since these APIs and approaches provide powerful ways of integrating continuous integration / continuous deployment (CICD) and version control patterns, whether you're using a single Qlik Cloud tenant, multiple Qlik Cloud tenants, or many tenants across multiple Qlik Cloud regions.

Qlik Cloud's multitenant model

Where you need to provide solutions to one or multiple users from distinct companies or organizations, you should deploy a multiple tenant solution in Qlik Cloud. Each tenant is deployed to serve each of these distinct sets of users, whether that be several, or tens of thousands of sets of users, and therefore tenants.

If you are deploying to a single organization, you can accommodate multiple teams and user groups in a single tenant, as Qlik Cloud offers logical separation of content via spaces for this use case.

Some example deployment use cases for Qlik Cloud leveraging the multiple tenant pattern include:

• A wealth management firm providing analytics embedded within their customer portal, allowing their customers (single user individuals or multi-user organizations) to view up-to-date account performance.
• A software company producing fitness and wellness mobile software where they provide analytics to their end users (single user individuals) in their mobile app.
• A logistics firm leveraging Qlik Analytics for providing tracking analytics to their customers (single user individuals or multi-user organizations) via embedding analytics in their public website.

Qlik Cloud's multiple tenant deployment pattern is an architecture where a Qlik partner receives a single entitlement (also known as license), which represents an organization inside Qlik Cloud. Within this organization, you can deploy multiple tenants - each a distinct logical instance. Although these tenants are linked to your organization, they are separate, so you will need to configure and hydrate these tenants independently.

Why deploy a tenant per customer?

The entitlements on a Qlik Cloud subscription (for example, the number of application automation runs that you are permitted to execute) are shared across tenants in a multiple tenant deployment.

Beyond this entitlement information, each tenant within Qlik Cloud provides logical separation of users, configurations, data, credentials, content, and any other assets that you or your users might wish to deploy.

Within a tenant, different asset classes are secured at different levels. For example:

• Users and user metadata are secured at the tenant level.
• Extensions and themes are secured at the tenant level.
• QlikView and Qlik Sense applications are secured at the space (or user/ group share) level.
• Analytics data connections and data files are secured at the space level.
• Data alerts are secured at the user level (but notifications can be sent to other users on evaluation).
• API keys are secured at the user level.

If you have requirements around securing any tenant-level assets such as users and user metadata, extensions, themes, and so on, then you should leverage a multiple tenant pattern. You should not deploy multiple organizations to a single Qlik Cloud tenant.

Other benefits of deploying a tenant per organization include:

• Ability to deploy different IdP configurations per organization.
• Ability to encrypt each organization's data with a separate key.
• Ability to customize the tenant to that organization, for example, through the deployment of organization-specific themes or extensions and naming conventions.

Entitlements

Qlik products require entitlements (also known as a license or subscription), which specify what features of the product are available to a partner. Some examples of attributes set in an entitlement include:

• Number of professional or analyzer user seats that can be assigned to users (for example, 100 professional and 100 analyzer licenses).
• Number of Qlik Cloud tenants that can be provisioned (for example, 1 tenant or 1,000 tenants)
• Which product features you have access to (for example, access to AutoML, Qlik Application Automation, and so on).
• Which tiers of certain products you have access to, such as a paid tier for Application Automation or Reporting Service.

In Qlik Cloud, all tenants in an organization share the same Qlik entitlement. This means that all attributes of that entitlement will be shared across all tenants, and by design, any tenant within the organization can request resources from the entitlement.

As an example, if the entitlement permits you an allowance of up to 10 professional user licenses across 5 tenants, it would be possible to assign all 10 user licenses to a single tenant, leaving no professional licenses for the other 4 tenants. As such, you must manage these resources during your provisioning workflows, through disabling settings such as automatic license assignment.

While each tenant within an organization is logically separated and data and logs are kept separate, the shared entitlement will mean that a user with access to the management console on any tenant in the organization will be able to view the full list of users and any assigned licenses for that organization. This means that you should not provide access to the management console to your end customers or users.

Programmatic provisioning, configuration & hydration in Qlik Cloud

To support the creation, configuration, and hydration of tenants for end customer onboarding in your applications, this series of tutorials demonstrates how the APIs can be used to:

• Create a new tenant.
• Configure the new tenant, including:
  • Configure an identity provider, typically either JSON Web Token (JWT) where integrating with existing applications, or an interactive provider such as Azure AD for other use cases.
  • Pre-provision groups for access control.
  • Configure license and role allocations.
  • Create and configure security on spaces (logical buckets within a tenant for securing content).
  • Configure web origin and content security policies for use with integrations or embedding.
• Deploy content to the tenant, including:
  • Import visualization extensions, themes and other content types required to provide customization of Qlik applications.
  • Import and stage Qlik applications in a shared space.
  • Publish staged applications to production-managed spaces.
  • Republish updated applications.
  • Deploy automations that automatically add new users to spaces (relevant if groups are not provided by your IdP for access control).

In addition to raw APIs, Qlik provides the Platform Operations connector in Qlik Application Automation. This provides you with a no-code method for deploying and managing content across your Qlik Cloud estate.

Authenticating to multiple tenants

Within a Qlik Cloud tenant, it is possible to generate API keys on a per-user level or OAuth clients on a per-tenant level to provide credentials for use with Qlik APIs.

To simplify user and credential management when you're managing more than one tenant, Qlik provides the ability for the Service Account Owner (SAO) of a subscription to set up regional OAuth clients in the My Qlik portal.

The first time an OAuth client is used for a request to a tenant, a corresponding non-interactive bot user is automatically created on the tenant. This user will be named based on the region the tenant is in, as shown in the diagram.

Actions performed by the bot user will be captured in the audit logs for the tenant. Any content deployed using the OAuth clients will be owned by the bot user.

Using these OAuth clients and the associated bot user will require up to one professional license per region, and acts with privileges equivalent to the TenantAdmin role on a tenant (the highest level of access available).

Recreating OAuth clients

The My Qlik portal provides the ability to create up to one OAuth client per Qlik Cloud region, and allows you to refresh the client secret for existing OAuth clients if required.

If you decide to delete an OAuth client via the portal, the associated bot user account will not be deleted from tenants automatically. Subsequently creating a new OAuth client in that region will result in a new, additional bot user being created when this new OAuth client is used on a tenant.

You will need to ensure that any content owned by an inactive bot user is deleted or reassigned to the active bot user account using APIs or the tenant management console.

Next steps

To begin the provisioning workflow and start spinning up tenants, go to Create a tenant.