
Multi-tenancy with Orgs
If your deployment requires logical separation of departments within your organization, or if it involves supporting many distinct organizations from a single application instance, use the Orgs feature. Using Orgs, you can set boundaries within the ThoughtSpot system and isolate each tenantβs data in such a way that it is independent of and invisible to other tenant workspaces configured on the same application instance.
The following figure illustrates the primary difference between a single-tenant and multi-tenant deployment:

Important
|
|
Orgs in ThoughtSpotπ
If the Orgs feature is enabled on your instance, a Primary Org will be created by default. This default Org is identified as Org 0
. The cluster administrator can create an Org for each tenant account, configure groups and assign users, and define access to data objects within that org. Each Org serves as an independent container with its own set of users, groups, and data objects, and provides the same user experience as that of a regular ThoughtSpot instance.
The following diagram depicts the Orgs presentation on a multi-tenant ThoughtSpot instance.

User rolesπ
On a multi-tenant instance, ThoughtSpot supports the following user roles:
-
Cluster administrator
By default, the administrator of the primary Org (Org 0) is assigned the privileges of a cluster administrator. The cluster administrator can access all Orgs and perform the following CRUD operations:-
Create and manage Orgs
-
Add users to Orgs
-
Administer cluster
-
Manage user identity and access management (IAM)
The cluster administrator can also act as an individual Org administrator and perform administration tasks within an Org context.
-
-
Org administrator
An Org administrator administers and manages users, groups, and data objects of their respective Org. Typically, Org administrators create groups within their Org and assign privileges to the users of their Org. -
Org users
An Org user can access only the Orgs to which they belong. A user can belong to more than one Org and access data objects and metadata based on the privileges assigned to the groups to which they belong.
All Orgs scopeπ
On a multi-tenant ThoughtSpot instance, all operations are run in the context of the Org.
If a cluster administrator wants to perform a Create, Read, Update, or Delete (CRUD) operation or apply a configuration change to all Orgs, they must override the Org context and apply the changes at the All
Orgs level via the UI or API calls. If using API, the cluster administrator must explicitly set the Org scope to ALL
in their API requests.
Note
|
|
Feature availability on a multi-tenant instanceπ
On an Orgs-enabled cluster, certain UI and API operations are allowed only at the cluster level. The following table lists the features and configuration operations allowed at the cluster or individual Org level.
Feature category | At the cluster (All Orgs) level | At the Org level |
---|---|---|
User management | β User creation and management β User association to Orgs | β User creation and management β User association to groups |
Groups and privileges | β | Groups and privilege configuration and management are restricted to Org context only. |
Authentication | β Local authentication configuration β Trusted authentication β SAML authentication configuration OIDC authentication configuration is not supported | β Trusted authentication |
Access to | β | β Access to the Develop tab at the Org level is disabled by default. To enable Develop tab and its features at the Org level, contact ThoughtSpot Support. |
Security settings (CORS and CSP for embedded instances) | β | CORS and CSP configuration via UI is supported only at the Primary Org (Org 0) level |
Data connections and objects | β | β Object creation and management β Data connection creation and management
|
Access control | β Org creation for data isolation β User mapping to Orgs | β Groups and privilege assignment to users β Object sharing with other users and groups in the Org |
Customization | β Custom domain configuration β From ID customization for system notifications β Onboarding settings and welcome message customization | β |
Style customization and CSS overrides | β | β In the 9.3.0.cl release, style customization settings can be applied only on the Develop > Customizations > Style customizations page. Per-Org CSS overrides can be applied using the Visual Embed SDK. To enable this feature on your instance, contact ThoughtSpot Support. |
Custom actions | β | β Custom action creation and group association are supported by default at the Primary Org (Org 0) level. To enable action customization at the Org level, contact ThoughtSpot Support |
Link customization for embedded instances | β | β |
Developer Playground | β | β |
REST API v1 operations | β Org endpoints for CRUD operations Group provisioning and custom action group association API operations are not supported. | All API operations are supported except for the CRUD operations of Orgs. |
REST API v2 Beta endpoints | β | β |
REST API v2.0 endpoints | β | β |
Authentication considerations for embedded appsπ
On a multi-tenant cluster with Orgs, ThoughtSpot supports local, SAML, and trusted authentication methods. If you are using Visual Embed SDK to embed ThoughtSpot in your app, use AuthType.Basic
for local authentication, AuthType.TrustedAuthToken
for trusted authentication, and AuthType.EmbeddedSSO
or AuthType.SAMLRedirect
for SAML SSO authentication. For more information, see Authentication.
Trusted authenticationπ
If Trusted authentication is enabled, Org users can obtain authentication tokens using the secret key
. Org administrator or an authorized third-party authenticator service can also generate tokens on behalf of a ThoughtSpot user by using the secret key
.
Starting from 9.2.0.cl, ThoughtSpot supports generating separate secret keys for each Org. To enable this feature on your instance, contact ThoughtSpot Support. When this feature is enabled, Org users can obtain separate authentication tokens to access their Org and switch between Orgs seamlessly.
Just-in-time user creation and dynamic privilege assignmentπ
If trusted authentication is configured in the SDK, you can request an authentication token via API calls to any of the following REST API endpoints:
-
REST API v1 -
/tspublic/v1/session/auth/token
-
REST API v2 -
/api/rest/2.0/auth/token/full
If the user doesnβt exist in the ThoughtSpot system, you can autocreate
a user account just-in-time and dynamically assign privileges by adding the user to groups
.
The /tspublic/v1/session/auth/token
API endpoint also allows you to define the Org context to which the user must be logged in to after successful authentication. However, the API requests to REST API v2.0 endpoint will automatically generate the token based on your current session context.
For more information, see Obtain an authentication token and Trusted authentication.
SAML authenticationπ
For SAML authentication, you must ensure that the Org support is enabled for SAML authentication. You must also configure the Org information on your IdP so that the SAML users are allowed to access the Orgs to which they belong. To enable Orgs support for SAML authentication on ThoughtSpot, contact ThoughtSpot Support.
The following conditions apply to SAML authentication on a multi-tenant setup:
-
If Orgs support is enabled for SAML authentication, and the Org objects to which the user belongs are configured on ThoughtSpot:
-
Multiple Org names can be sent in the SAML assertion.
-
If the Org names are not sent in the SAML assertion, the user is logged in to the default Org (Primary Org).
-
If the user already exists in ThoughtSpot, the user is allowed to access the Orgs sent in the SAML assertion.
-
If the user does not exist in ThoughtSpot, the user is assigned to the Orgs sent in the SAML assertion but is not assigned to any group.
-
If the user is already created in ThoughtSpot and assigned to Orgs and the SAML assertion has different Org names, the user is assigned to only the Orgs sent in the SAML assertion. For example, if a user belongs to Org A and Org B and the SAML assertion includes Org C and Org D, the user is assigned to Org C and Org D and removed from Org A and Org B.
-
-
If Orgs support is enabled for SAML authentication and the Org objects are not configured ThoughtSpot, the authentication process returns an error.
-
If the Orgs support is not enabled for SAML authentication and Org objects are not configured, the user is assigned to the default Org (Primary Org).
Get started with Orgsπ
Note
|
Before you get started with Orgs, make sure you read the documentation and understand the features supported on a multi-tenant setup. |
To get started with Orgs:
-
Configure your ThoughtSpot instance as a multi-tenant cluster. To enable multi-tenant setup on your instance, contact ThoughtSpot support.
-
Log in to your application instance as an administrator.
If the Orgs feature is enabled on your cluster, a Primary Org is created by default, and you will be logged in to the Primary Org context.
-
Create Orgs in the Admin page of the UI or via REST API.
To create and manage Orgs, you must set the Org context to
All
. To do this, you can switch to the All Orgs tab in the Admin page of UI or pass the Org scopeALL
in your API requests to Orgs API endpoints. For more information, see Org API. -
Create users and map the users to Orgs.
You can create an administrator profile for each Org and let these Org administrators manage users, groups, and role privileges in their respective Orgs.
Note that ThoughtSpot allows provisioning groups only within the context of an Org. You must ensure that ThoughtSpot users are mapped to appropriate Orgs and the groups within these Orgs for user access control and data security.