Single vs multiple tenants

Most platforms offer some form of multi-tenant model, although few provide full logical isolation in a SaaS product.

What is a tenant?

In Qlik Cloud, a tenant is a logical container within a SaaS regional deployment. It is designed for collaboration within an organization, tied to a geographical region, and includes all Qlik Cloud capabilities. From a consumption perspective, you can see it as the Qlik Cloud product in a box.

For more information on the relationship of tenants with the rest of the Qlik Cloud infrastructure, see Platform Operations overview and the Qlik.com trust page.

Tenant deployment patterns

Qlik offers both industry leading full tenant SaaS isolation, shared multi-tenant SaaS, and client-managed & SaaS hybrid deployment patterns:

• Multiple tenant: a full-featured, secure, and scalable solution whereby each customer of the Qlik OEM partner receives their own, logically isolated tenant. These tenants are no different to those you would purchase as a direct Qlik customer, other than they are managed and controlled by you, the OEM partner, rather than the end customer.
• Single tenant: a limited deployment pattern for simple analytics without collaboration capabilities, where no user personal identifiable information (PII), such as end user names or emails, is stored on the tenant. This is not recommended for a production deployment, except for very specific use cases.
• Client-managed hybrid deployment: Qlik provides the base Qlik Sense component of Qlik Cloud Analytics as client-managed software which can be installed and managed by you, the OEM partner.

Contracts reference the Product descriptions for Qlik Cloud Subscriptions, which requires that:

When providing Qlik Cloud Analytics access to multiple organizations, it is required to utilize separate Tenants for each separate organization.

The following sections explain why a multiple tenant deployment is preferred and detail the use cases where you might consider a single tenant solution.

Multiple tenant deployment

When you need to provide solutions to users from different companies or organizations, you should deploy a separate tenant per organization in Qlik Cloud. Each tenant serves its own sets of users, whether it’s a few or tens of thousands.

This has benefits such as:

• Total data segmentation: data, such as personal and usage information or customer-specific data, is isolated. With a tenant per customer, data deletion and customer offboarding becomes as simple as deactivating the tenant and purging it from Qlik Cloud.
• Full per-customer customization and branding: all tenant settings, features, and capabilities can be fully configured to suit the customer or the product they have purchased from you.
• In-product collaboration options for products which leverage Data Alerts, Notes, Subscriptions, or other action-oriented capabilities.

Consider a multiple tenant deployment as the default option when deploying Qlik Cloud to external organizations.

In this pattern, every customer receives their own Qlik Cloud tenant, and the OEM retains full control of these tenants.

In this example, tenants have been deployed from a single OEM license to three Qlik Cloud regions:

• oem.us.qlikcloud.com: the OEM development and testing tenant is deployed to a Qlik Cloud US region, where the OEM developers are based. This tenant includes shared spaces for content development and testing, and a managed quality assurance (QA)/prerelease space. This tenant doesn’t contain customer data and isn’t accessible by customers. If preferred, dev, test, and QA can be further separated. QA tenants can be spooled up on demand before a release.
• cust-a.us.qlikcloud.com: this customer tenant is deployed to the same Qlik Cloud US region as the OEM development tenant. The customer is also located in this region. The tenant is co-located with the customer for performance reasons or data-residency requirements.
• cust-b.eu.qlikcloud.com: this customer tenant is deployed to a Qlik Cloud EU region as the customer is located in Ireland. The tenant is co-located with the customer for performance reasons or data-residency requirements.
• cust-z.uk.qlikcloud.com: this customer tenant is deployed to a Qlik Cloud UK region as the customer is located in England. The tenant is co-located with the customer for performance reasons or data-residency requirements.

A multi-tenant deployment should follow these good practices:

• Each customer and their data and users should be located on separate tenants.
• Tenants should be geo-located as close to their customer as possible to enhance the user experience and comply with data privacy and residency requirements.
• The OEM team should work on their own tenant and use automation to deploy to customer tenants.
• Customer apps should be staged in shared spaces, and consumed from managed spaces.

Single tenant deployment

The single tenant pattern is not recommended, given the advantages of the multiple tenant pattern for Qlik OEM partners. However, consider a single tenant deployment in the following cases:

• All users access anonymously or with anonymized user data.
• You are handling very large apps that are not cost-effective to be delivered in a multiple tenant deployment and are providing only basic embedded analytics.

If you deploy multiple customers to a single Qlik Cloud tenant, any user can view names, emails, and other information about other users in the tenant. For more information on content security in a tenant, see Platform Operations overview.

While the tenant architecture and automation is simpler in this deployment pattern, ensure your projected usage remains within the tenant-level guardrails described in the Qlik Could Analytics specifications and capacity (if on a Capacity entitlement) or Qlik Sense Enterprise SaaS and Qlik Sense Business help topics.

This diagram shows a single tenant (oem.us.qlikcloud.com) deployed from a single OEM license to one Qlik Cloud region.

In this example, the OEM development, testing, and other teams use the same tenant as the customers. There are shared spaces for content development and testing, and a managed QA/pre-release space for QA by the OEM before release. Each customer has a shared and a managed space, with consumption limited to the managed space.

A single tenant deployment should follow these good practices:

• Anonymize or scramble user information to avoid PII leakage and facilitate user offboarding and data clean up.
• Turn off collaboration features in the tenant and use dummy email addresses.
• Embed the experience to further reduce the risk of users accessing collaboration features that may not have been turned off.
• Ensure users are in the same region as the tenant for consistent performance.
• There should be no customer-specific data residency or encryption requirements.
• Stage customer apps in shared spaces and have them consumed from managed spaces.

Client-managed hybrid deployment

Qlik Sense Enterprise Client-managed is a self-host software which provides the core features of Qlik Sense in Qlik Cloud, without features such as collaboration, automation, alerting, reporting, AI, or data integration. It provides an approach for delivering base analytics to customers with very stringent data privacy and security requirements that Qlik Cloud can’t meet.

While most visualization options in Qlik Sense in Qlik Cloud are compatible with Qlik Sense Enterprise Client-managed, advanced features requiring components that are uneconomical or impractical to deploy on a customer-managed Microsoft Windows server (for example, direct query to database for big data solutions or advanced AI helpers) will not be available. Additionally, unlike Qlik Cloud’s continuous release cadence, client-managed has a fixed release schedule, which may delay access to the latest updates and capabilities.

If you deploy a SaaS and client-managed hybrid, you will need to provide your own automation tooling to manage the client-managed portion of your deployment.

Tenant option overview

An overview of patterns:

Patterns	Usage scenarios
Multiple tenants	Suitable for most scenarios, except anonymous access or use cases requiring hundreds of thousands of tenants
Single tenant	Anonymous, basic analytics only, no user PII, and when the solution fits within one tenant’s guardrails
Client-managed hybrid	Where a subset of your customers have very strict data security or locale requirements and require basic analytics only

Next steps

Move onto the next section, or go back to the playbook introduction.