1. Overview

Dundas BI has built-in support for multi-tenant deployment scenarios, allowing administrators to easily create and manage tenants (clients), which are isolated from each other under a single deployment.

The most common use of a multi-tenant instance is for a SaaS solution provider who wants to enhance their software BI and analytics capabilities by integrating Dundas BI into it (hosted OEM/ISV scenario). There are other cases where a multi-tenant instance may be beneficial, such as a deployment of a client-facing portal, or a large internal deployment that requires complete isolation between different departments/lines of business.

2. Multi-tenant instance

A multi-tenant instance is used when the application deployment is done for users who shouldn’t know about the existence of other users using the same system. It allows the solution provider to install and maintain one application of Dundas BI to handle all their tenants.

A simple multi-tenancy structure would be when each tenant (client) has their own database, but the solution provider hosts only one instance of Dundas BI. Assuming the database structure is the same across all tenants, Dundas BI allows you to create a single set of dashboards and reports and reuse it across all the tenants, rather than maintain a separate copy for each, by using data connector overrides.

A simple multi-tenancy structure with data connection overrides
A simple multi-tenancy structure with data connection overrides

The same scenario of reusing dashboards and reports is possible even if the data for all the tenants is stored in a single database. In this case, the data of each tenant will be identified by a tenant ID or a similar field, and will be secured using custom attributes, or provider security options like using SSAS roles impersonation if the data source is an OLAP cube.

A multi-tenancy structure with custom attributes
A multi-tenancy structure with custom attributes

2.1. Access security and isolation

Every tenant user can only see objects (e.g., dashboards) his tenant is allowed to see. Any object created by a tenant user will not be visible to users that belong to other tenants, thus completely separating users from different tenants. In addition, users that belong to a certain tenant can only see users that belong to the same tenant (for example if a list of users is displayed when sharing a dashboard).

2.2. Commercial alignment and licensing control

Specific allocation of licenses per tenant allows multi-tenant solution providers to match their different tenants' licensing needs. This is important in cases where the tenant buys licenses for their own users. This can allow an SaaS provider to monetize their analytics solution by selling specific licenses (e.g., Power User licenses) to their tenants.

2.3. Data security

Multi-tenant deployments allow for overriding data connectors for each tenant. This option should be used in the case where every tenant has its own database, but the same database structure is being used across all tenants. When the tenants share the same database but should see only their own data, custom attributes can be used for data security. Both of these options allow the solution provider to create a single set of dashboards for all tenants.

3. Adding a new user account to a tenant

Tenant administrators have the ability to add new accounts to the tenant, set up their custom attributes, and assign available license seats to those accounts. The membership of the Tenant Administrators group can be edited from the Groups page in administration, found under Account Service.

Editing the Tenant Administrators group
Editing the Tenant Administrators group

To add a new account to the tenant, go to the Admin screen, expand Account Service and click Accounts. Add a new account and set its tenant field to an existing tenant name.

Adding user account to the tenant
Adding user account to the tenant

Once the account has been added to a tenant, it cannot be moved to another tenant.

4. Content sharing between tenants

Content can be accessed by different tenants only when created by a user that isn’t associated with any tenant. The content will be located typically in the global project, but can also exist in other projects as long as the tenant members have at least Read access to it. A shared project can be beneficial when multiple tenants have a similar dashboard structure with the same or different data, so that the solution provider does not have to replicate the efforts across all tenants.

Similarly, the share as a link option will only list users that the sharing user is allowed to see: if they don't belong to any tenant, they will be able to see all users under the share dialog, otherwise they can only see users associated with the same tenant.

5. See also

Dundas Data Visualization, Inc.
500-250 Ferrand Drive
Toronto, ON, Canada
M3C 3G8

North America: 1.800.463.1492
International: 1.416.467.5100

Dundas Support Hours:
Phone: 9am-6pm, ET, Mon-Fri
Email: 7am-6pm, ET, Mon-Fri