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 which 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.
Where you need to provide solutions to one or multiple users from distinct groups, companies, or organizations, you should deploy a multitenant 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.
Some example deployment use cases for Qlik Cloud leveraging this multitenant 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 multitenant 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.
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 multitenant 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, etc., then you should leverage a multitenant pattern. You should not deploy multiple organizations or groups of users 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
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, etc.)
- 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.
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 which automatically add new users to spaces (relevant if groups are not provided by your IdP for access control)
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
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
Using these OAuth clients and the associated
bot user will require up to 1
professional license per region, and acts with privileges equivalent to the
TenantAdmin role on a tenant (the highest level of access available).
My Qlik portal provides the ability to create up to 1 OAuth client per Qlik
Cloud region, and allows you to refresh the client secret for existing OAuth clients
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.
To begin the provisioning workflow and start spinning up tenants, go to Create a tenant.