Multi-tenancy with Orgs

The Orgs feature is off by default. To try out this feature, contact ThoughtSpot Support. To learn about multi-tenancy using groups instead of Orgs, refer to Multi-tenancy with groups.

The multi-tenancy feature allows a ThoughtSpot cloud instance to be logically partitioned into multiple tenant-specific environments called Orgs. With Orgs, each tenant’s data is isolated and protected with access control, and is invisible to the other tenants that share the same ThoughtSpot application instance.

If the Orgs feature is enabled on your instance, your cluster administrator can create an Org for each tenant account, configure groups and users, and control access to data objects. Each Org serves as an independent container with its own set of users and data, and provides the same user experience as that of a regular ThoughtSpot instance.

This article is an overview of the Orgs functionality and Org management in the standard ThoughtSpot Cloud environment. To learn more about Orgs functionality and programmatic Org management using REST APIs in the ThoughtSpot Everywhere environment, refer to Multi-tenancy with Orgs. To learn more about Orgs APIs, refer to Orgs API.

After you enable the Orgs feature on a cluster, you cannot disable it. However, your environment remains a single-tenant environment until you create an Org, and you can return to single-tenancy by deleting all the Orgs you created.

Orgs in ThoughtSpot

If the Orgs feature is enabled on your instance, only one Org exists by default. ThoughtSpot refers to this default Org as the Primary Org. The cluster administrator is the administrator of the Primary Org. The administrator of the Primary Org can create more Orgs, add an administrator user profile to each Org to manage users and groups, and define access control at the Org level. The administrator of any other Org, referred to as an Org administrator, can only administer their Org. Only administrators of the Primary Org can administer across Orgs.

The following diagram depicts the Orgs architecture on a multi-tenant ThoughtSpot instance.

Org logical architecture diagram
  • The Primary Org cannot be deleted.

  • Each Org is identified by a unique name and can have its own users and groups.

  • Groups are unique to an Org and can be created only within the context of an Org.

  • A user can belong to multiple Orgs.

Multi-tenant isolation

ThoughtSpot ensures complete Org isolation in a multi-tenant environment. Specifically, when you use the Orgs feature, ThoughtSpot ensures that all of the following are restricted to their particular Org:

  • Cloud data warehouse connection

  • Cloud data warehouse data

  • Groups

  • Users

    • Note that users can belong to multiple Orgs, but at any given time can only access the data and objects of their current Org.

    • If users belong to multiple Orgs, they can switch their current Org context to one of the other Orgs they belong to.

    • Users have no awareness of Orgs they do not belong to.

  • ThoughtSpot objects: Liveboards, Worksheets, Answers, and tables. You cannot share objects between Orgs.

  • Search data content and indexing

  • Search Answers content and indexing

  • Other indexing

User roles

On a multi-tenant instance, ThoughtSpot supports the following 3 user roles: cluster administrator, Org administrator, and Org user. By default, the administrator of the Primary Org is a cluster administrator. The cluster administrator can access all Orgs and perform CRUD (Create, Read, Update, and Delete) operations on all Orgs. The cluster administrator can also switch between Orgs and also act as an Org administrator.

Org administrators can administer and manage users and groups only of their respective organizations, not all Orgs. Users can belong to more than one Org and access data objects based on the privileges assigned to the groups to which they belong. The following diagram depicts the setup for users on a multi-tenant ThoughtSpot instance.

Org user setup diagram

Cluster administrators and Org administrators

Cluster administrators and Org administrators have some of the same privileges and responsibilities. While these roles overlap, they are not the same.

Cluster administrators can do the following tasks:

  • Org management: creating, editing, and deleting Orgs

  • User management for any user in any Org

  • Group management for any group in any Org

  • Connection management: creating, editing, and deleting any connection in any Org

For a cluster administrator, the Admin Console in the Primary Org has an All orgs section, to manage cross-Org configuration, and a Primary org section, to manage configuration for the Primary Org.

Org admin console for the cluster administrator

Org administrators can do the following tasks:

  • User management for any user in the Org(s) in which the Org administrator has admin privileges

  • Group management for any group in the Org(s) in which the Org administrator has admin privileges

  • Connection management: creating, editing, and deleting any connection in the Org(s) in which the Org administrator has admin privileges

For an Org administrator, the Admin Console does not have an All orgs section. The Org administrator can only manage configuration for their specific Org.

Org admin console for the Org administrator

Create and manage Orgs

To create an Org on a multi-tenant ThoughtSpot instance, you need cluster administrator privileges. By default, the administrator of the Primary Org is a cluster administrator. The cluster administrator can create Orgs using either the UI or the REST v1 API endpoints. The cluster administrator can also edit and delete Orgs.

For information on how to create, edit, and delete Orgs, refer to Orgs administration.

To create Orgs using the REST v1 API endpoints, refer to Orgs API.

Switch between Orgs

Any user with access to multiple Orgs can use the Org switcher in the top navigation bar, next to the help icon, to switch between the Orgs they belong to. The Org switcher also identifies the Org the user is currently in. For example, in the following image, the user is in the Primary Org.

Org switcher

A user only sees the Orgs they belong to in the Org switcher. If a user is only part of one Org, they do not have the option to switch between Orgs. They only see the one Org that they belong to.

A cluster administrator can access several Org objects and apply configuration changes. Before performing any operation on the objects in an Org, the administrator must specify the correct Org to ensure that configuration changes are applied in the relevant Org context.

org switcher gif

All Org scope

On a multi-tenant ThoughtSpot instance, all operations are run in the Org context that the user is currently in. If a cluster administrator wants to perform a CRUD (Create, Read, Update, or Delete) operation or apply a configuration change to all Orgs, they must be in the Primary Org, in the All orgs section of the Admin Console.

For example, to add a user to multiple Orgs, the administrator must be in the Primary Org, in the All orgs > Users section of the Admin Console. If the administrator is in Org 1, for example, the Users section of the Admin console does not have the option to add users to Orgs, only to groups. You should only use the All orgs > Users section of the Admin Console to add users to multiple Orgs. Use the individual Org’s Admin Console > Users section to add users to individual Orgs, and to add users to groups.

Cluster-level configurations

The following features can only be configured or viewed on a cluster level, for all Orgs. You cannot configure these features to work in different ways for different Orgs in the same cluster. Therefore, the cluster administrator must perform the configuration or other management of the following features:

  • Adding users to multiple Orgs at a time

  • Identity and Access Management: local and SAML user authentication

  • Style customization

  • User adoption Liveboard

  • Performance tracking Liveboard

  • Billing information: Credit Usage Liveboard

  • Developer functionality and features, including custom actions.

  • Custom calendar

  • Search and SpotIQ settings

  • Email and onboarding settings

Manage users and groups

On a multi-tenant instance, the cluster and Org administrators can create and administer users and groups. The cluster administrator can perform CRUD (Create, Read, Update, and Delete) operations on user and group objects of all Orgs, whereas the Org administrator can create and administer users and groups only in the Org context to which they belong.

To manage Org groups, the cluster administrator must switch to the appropriate Org. This includes management of the groups a specific user belongs to. To manage Org users, the cluster administrator can be in the primary Org or the specific Org the user belongs to.

You should only use the All orgs > Users section of the Admin Console to add users to multiple Orgs. Use the individual Org’s Admin Console > Users section to add users to individual Orgs, and to add users to groups.

For information on how to add, remove, and manage users and groups in Orgs, refer to Orgs administration.