Provisioning 100+ Qlik Cloud tenants on an OEM subscription

One of the great things about the Masters Summit for Qlik is that, alongside teaching, I always have the chance to learn something new. For last year’s event in Vienna, we revamped 80% of our curriculum, focusing heavily on Qlik Cloud. To give attendees the full cloud experience, we provided each person with their own individual Qlik Cloud tenant. I was responsible for provisioning these 100+ tenants. It was a rewarding and educational task that I was happy to do again this year for our event in Hamburg. In this blog post, I’ll share some of my experiences, observations and lessons I learned along the way.

The challenge

Qlik Cloud OEM

We presented this plan to Qlik, and they generously offered us a trial OEM subscription. This allowed us to create a separate tenant for each student. My next task was to set up around 100 identical tenants, aiming to reduce manual work as much as possible.

What is Qlik Cloud OEM?
Qlik Cloud OEM is the version of Qlik Cloud designed for partners who need to provision, manage, and embed analytics environments at scale. Instead of a single tenant for one organization, an OEM subscription allows you to programmatically create and control many isolated Qlik Cloud tenants, each with their own users, apps, and data connections.

Where a typical Qlik Cloud Enterprise customer runs one centralized tenant for internal use, an OEM partner operates at a higher level, creating dedicated Qlik environments for end customers, training participants, or application users. This model provides full isolation between tenants while still allowing centralized management, automation, and deployment.

The plan

The initial plan was simple: the instructors at the Masters Summit for Qlik would develop their materials in a centrally shared tenant. We would then create automations to create the empty tenants and distribute the materials to them. Once the materials were finalized, they would be copied to each tenant. Finally, we would assign a student to each tenant and send out invitations for access.

All in all, we needed to create / distribute many different artifacts, including the following things:

Creating tenants

I used Qlik Automate and the Qlik Platform Operations connector to build an automation (shown partially below) to create the tenants.

Besides creating the tenants, this automation also does the following things:

• Store information about each created tenant in a glossary (more on that later)

• Add all Masters Summit for Qlik instructors as an admin to the tenant, so they can access the tenant and support students when required.

• Set an alias for the tenant that is easier to remember for the student (and easier to share with instructors). For example: masterssummit-123.de.qlikcloud.com instead of iyj7m6znw3ispc6.de.qlikcloud.com

• Apply the Masters Summit for Qlik branding to the tenant.

Storing tenant information

One of the first ‘gotchas’ I ran into when creating tenants is that, if you don’t immediately store the tenant information it can seem as if they disappear into thin air. This isn’t actually the case, as they’re always listed in the tenant list in your “My Qlik” profile, but that isn’t very helpful if you want to access them programmatically.

Using Glossaries as a poor man’s database

Since I needed somewhere to store tenant metadata, I decided to repurpose a feature already available in Qlik Cloud: a Qlik Glossary. A Qlik Glossary is normally used to document business terms, their definitions, and related metadata within a Qlik Cloud tenant. It is intended as a governance and documentation feature, not as a data store. However, because glossaries support custom properties, tagging, and an API interface, they can conveniently hold structured information. By treating glossary entries as records, you can store and retrieve lightweight data such as details about each provisioned tenant without needing an external database.

Each entry in the glossary stores the host name of a tenant, which user is assigned to the tenant (or blank for unassigned tenants) and the moment when the tenant was last populated (or “hydrated”).

So far, so good!

Everyone has a plan until they get punched in the face

With all the empty tenants created, the next step was to “hydrate” them with the required materials. This part required some improvisation, since a few gaps in my original plan quickly became apparent:

• QVD’s stored in the catalog / DataFiles can’t be easily exported (can’t believe I missed this!)

• Apps larger than ~ 20 MB can’t be exported / imported through an Automation

• And the biggest flaw: the verbosity, endless clicking and dragging, and the absence of easy debugging or partial runs made working with automations increasingly frustrating. My blood pressure may have reached dangerous levels.

Improvise, adapt, overcome: Qlik CLI

Fortunately, Qlik offers multiple ways to connect to and manage Qlik Cloud environments. At their core, they all rely on the Qlik Cloud REST APIs; the only real difference is the level of abstraction or convenience wrapped around them. Options range from bare API calls using, for example, cURL or Python to low-code blocks in Qlik Automate. My preferred method is Qlik CLI, a command-line interface for managing and automating tasks in Qlik Cloud and Client-Managed environments, provided as a set of PowerShell commands.

Qlik CLI provides a simple and predictable syntax for interacting with a Qlik tenant. For example:

These commands list all spaces, apps, and automations that are available to you. It is not limited to read-only operations either; you can also perform actions such as reloading an app:

qlik app reload --app "aa69d90a-4843-4486-82c8-d5b922fada4b"

When combined with the scripting capabilities of PowerShell, Qlik CLI becomes a powerful tool for building your own automations. For example, the (simplified) function below uploads all applications within a specified folder to a given space:

function Import-QlikApps {
    param (
        [string]$path,
        [string]$spaceId
    ) 

    $files = Get-ChildItem -Path $path
    foreach ($file in $files) {
        qlik app import --file="$file" --spaceId=$spaceId
    }
}

With a collection of helper functions in place, many of which I already used for regular tenant management, it became easy to start composing more complex automations. I applied the same concept to create a script that could “hydrate” a newly created tenant by uploading apps, setting up data connections, applying themes, and restoring other artifacts. The script could also “rehydrate” a tenant if something broke or if (when!) one of the presenters had last-minute additions to their materials.

Hydrating Qlik tenants

The video above shows the hydration process for a single Qlik Cloud tenant. Running this for a hundred tenants would be a bit much to watch, but the steps are identical. In this example, the script retrieves the tenant information from the glossary in the main tenant, then connects to the target tenant to populate it. If the tenant was previously hydrated, the existing materials are removed first before repopulation begins.

The actions performed include importing apps and data, creating data connections, restoring automations, glossaries, report templates, themes, and links, reloading apps, moving automations, assigning rights to spaces, assigning roles, and applying various global tenant settings such as email configuration.

What once took days of manual setup can now be done automatically in just a few minutes per tenant.

Observations and thoughts

At Bitmetric we frequently use both Qlik Automate and Qlik CLI to deploy and manage client environments, including lifecycle management and configuration. The process I built for the Masters Summit followed the same principles, but the context was quite different. Instead of a few production tenants, I was now spinning up and hydrating more than a hundred temporary training environments in a short timeframe. That change in scale and purpose surfaced a few interesting observations.

User-based subscriptions and shared license pools

One interesting discovery was how user-based subscriptions behave in an OEM setup. Users are shared across all tenants under the subscription, which means that administrators in sub-tenants can also create new users. During the Vienna event, when we were still using a user-based trial license, there was no way to prevent this. As a result, any tenant admin could unknowingly use up the available user licenses for the entire environment.

I’m not sure if this still works the same way today, but I haven’t seen anything to suggest it has changed. For our Hamburg event we used a capacity-based tenant, which completely removes this limitation, since that model allows for an unlimited number of users.

CLI scripting makes experimentation easier

Working in PowerShell with Qlik CLI turned out to be much faster and more flexible than using Automate. Being able to test individual commands directly from the command line made it much easier to prototype and debug the process. Instead of rebuilding and re-running entire automations, I could adjust one line, run it, and immediately see the result. That kind of feedback loop is invaluable when you are iterating on something complex.

The only downside is that deploying a solution like this requires an additional environment for running the scripts, while Qlik Automate is already included within the product. Still, for one-off projects, experiments, or time-sensitive work, Qlik CLI is usually the more practical choice.

Role and Space assignment shortcut

Since this was a temporary training setup, I took a few shortcuts. Instead of assigning roles per user, I gave every role to the built-in everyone in tenant group (identified by group id 000000000000000000000001), excluding only Embedded Analytics User, which blocks access to the Hub. With a quick qlik role ls and a patch to that group, everyone had full access and fewer permission issues to troubleshoot. The same trick also worked to provide “everyone” with the correct access to all relevant spaces. Again, not something you should do in production, but very useful in a training environment.

Working around Qlik CLI limitations

Qlik CLI is a great tool, but it sometimes lags behind what’s available in the Qlik Cloud API. Fortunately, it includes the qlik raw command, which lets you communicate directly with any API endpoint. I used this to add pinned links to the tenant and to move automations into shared spaces. It’s a handy escape hatch when you need functionality that hasn’t yet been exposed in the CLI.

The glossary hack held up surprisingly well

Using a glossary as lightweight data storage worked even better than expected, and I’ll definitely use the same approach again when I need to store data from automations or other scripts. The only caveat is that you need to trust the people in your tenant not to “tidy up” your glossary. It’s a great solution for controlled environments, but maybe not for those without adult supervision.

I could also have used local files to store the same information and process them with PowerShell. However, the glossary had one big advantage: every instructor could easily see which tenant belonged to which student by simply looking up their email address. That made helping attendees much faster and easier during the event.

Qlik CLI or Qlik Automate, both get the job done

Even though I used Qlik CLI for this project, everything I did could have been achieved with Qlik Automate as well. In this case it mostly came down to familiarity, personal preference, and a lot of time pressure. When I need speed and flexibility, I gravitate toward scripting, but Automate remains a solid option for teams that prefer a visual approach.

Sometimes skipping a few corners is OK

Just like with the group assignments, I probably cut a few corners when it comes to error handling, validation, and general robustness. In a production environment I would obviously spend more time on those details, but for a temporary training setup this level of pragmatism was perfectly acceptable.

Reliable and stable under pressure

Qlik Cloud performed flawlessly throughout this entire process. Even with all my experimentation, testing, and occasional mistakes, I couldn’t break anything that couldn’t be easily fixed. Reloads, imports, and API calls all behaved as expected, and failed operations were easy to retry. It gave me a lot of confidence that the platform can handle large-scale automation without getting in the way.

The documentation and help within Qlik CLI and on Qlik.dev also deserve a mention. Both are clear, well-structured, and made it easy to find the right commands or API endpoints when I needed them. In most cases, simply appending --help to a Qlik CLI command was enough to move me forward. For a project that relied heavily on experimentation, that level of documentation quality made a big difference.

Enjoying the process

Even with the time pressure and short deadline, I genuinely enjoyed building this. I started way too late, both times, but fortunately I already had a lot of reusable pieces available. Some of my colleagues joked, “Nice, now that all that boring stuff is out of the way I can get started on the fun things,” so not everyone shared my enthusiasm for the automation part. And that is fine. What I loved was knowing that everything was now fully automated and that they could focus entirely on delivering high-quality content to our attendees.

Then again, automating the manual and boring parts is also part of our job. The better we get at removing friction behind the scenes, the more time others can spend on what really matters: creating insight and value for users.

Conclusion

This project was a great reminder of how powerful Qlik Cloud has become as an automation platform. Whether you are creating new tenants, promoting content between environments, managing users, or handling lifecycle operations, nearly every part of the platform can now be automated. The combination of a robust API layer, excellent documentation, and tools like Qlik CLI and Qlik Automate makes it possible to build repeatable, scalable processes that save time and reduce errors.

For OEMs, the same strengths extend even further. If you are embedding analytics into your own product or need to provision and manage isolated environments for customers, Qlik’s OEM model is, in my opinion, the best offering on the market today. It provides the right balance of flexibility, control, and reliability without getting in your way.

If you are exploring these kinds of automations, or considering how Qlik Cloud can fit into your own solution, feel free to reach out. I am always happy to share ideas, compare notes, or help you get started.

More from the Bitmetric team