One Qlik Cloud tenant, several white-label portals: how NewHub's multiple workspaces work

NewHub lets you create more than one workspace pointing at the same Qlik Cloud tenant. Each workspace has its own address, its own visual identity and its own menu, and all of them read the same apps and spaces from the tenant you already set up. The address can be the client's own domain, with no NewHub or Qlik branding anywhere in the browser bar. For anyone selling data analysis as a product, that solves a problem that, until now, only had an expensive way out.

The cost of delivering the same product to different clients

An OEM or ISV partner builds the product once: data model, loads, apps, spaces, access rules. Then sells that product to ten, forty, a hundred clients. Each client wants to sign in at an address they recognise, with their own logo on screen and the name their team already uses day to day, not the vendor's brand.

There used to be two ways out. Either everyone signed into the same portal, under the partner's identity, which weakens the sense of a dedicated product. Or the partner replicated the environment per client, and then every fix to an app becomes forty releases, every rule change becomes forty adjustments, and the cost of maintaining the product grows at the same pace as the client base.

What changes with several workspaces on the same tenant

A NewHub workspace is the consumption layer, not the data environment. The tenant stays one, the apps stay published once, the loads still run once. What now exists in several versions is the experience: address, logo, palette, typography, menu organisation and the names given to the analyses.

In practice, the same billing app can show up for one client inside a blue portal called "Commercial Indicators" and, for another client, inside a green portal called "Sales Dashboard", with no duplication behind either.

The address can be entirely the client's own

By default, each workspace is born on a NewHub subdomain, in the form client.newhub.com, which is already enough when the partner wants to separate environments quickly or put together a demo.

When the product needs to be delivered as the partner's own, the workspace runs on its own domain. The client reaches portal.theircompany.com, or whatever address the partner defines, and NewHub's or Qlik's brand never shows up anywhere in the navigation. Logo, colours, typography and naming follow whatever identity the partner wants to apply, workspace by workspace. From the user's side, these are different products. From whoever maintains it, it is a single environment.

How this looks in practice

Say you already have the tenant set up, with the apps in the right spaces and the users invited. The address you use for sales demos keeps working exactly as it did before.

You create a second workspace for Client A, point their domain at it, apply their visual identity, set up the menu with the language their team already uses, and invite the users. Create a third for Client B, with a different brand, a different domain and a different menu cut. All three addresses answer the same tenant, read the same apps, and keep receiving any improvement you publish, with no replication and no parallel version.

It is the same model behind the Mersy case, which delivers analytics to its own end clients under its own brand.

What stays Qlik Cloud's responsibility

The workspace defines what each client sees as a product, not what they are allowed to see. The separation between clients keeps happening where it always has: in Spaces, in each user's permissions and, when the case calls for it, in the apps' Section Access. Authentication, identity provider and governance stay in Qlik Cloud.

Worth noting a point that tends to come up with regulated clients: NewHub only stores metadata, meaning the menu structure, the reference to the apps, the analyses' definitions and the usage logs. Analytical data never passes through NewHub or gets stored in it.

Uses outside the OEM scenario

The same capability solves internal situations too. A leadership team that wants a lean portal, with a handful of indicators and its own visual identity, while the operation uses a different address with the full menu. Sales teams that keep several demo environments running, each one wearing the face of the prospect they are visiting that week, all pointing at the same set of demo apps.

Frequently asked questions

Do I need a Qlik Cloud tenant for every client?

No. NewHub workspaces point at the same tenant, and what each client sees is segmented by the Spaces and the permissions you already set up in Qlik Cloud.

Do I need to duplicate the apps for every client?

No. The app is published once and shows up in every workspace that has access to it. A fix made to the app applies immediately to every client.

Can each workspace have a different URL?

Yes. The default is a subdomain in the form client.newhub.com, and there is the option of using a domain that belongs to the client or to the partner, with no reference to NewHub or Qlik anywhere in the address.

Can one client see another client's data?

Access to the data is controlled by Qlik Cloud. If the user has no permission on the space, or is restricted by Section Access, they do not see the content, regardless of which workspace they signed into.

Do my clients' users need a Qlik license?

Yes. Every user who signs into a NewHub workspace needs authentication and sign-in already set up in Qlik Cloud, on the same tenant. NewHub does not create users or replace Qlik's access control, it presents the already-authenticated user with the content they are allowed to see.

Does this work for internal use, not just OEM?

Yes. Different areas of the same company can have portals with different identities and menus on top of the same tenant.

If that is your case, book a demo and see how it looks on your own tenant.