Multi-tenancy within an Org

Whether users can see each other is controlled by group membership and a property called shareability. Please see the documentation on access control and sharing to learn how to configure the shareability properties for users and groups to achieve separation within a single Org.

In a multi-tenanted database, there is typically a column named “customer_id” or “tenant_id” on every row of data within the database; we’ll call it the tenant key.

Filtering against this tenant key splits the data for each end customer organization.

If the cloud data warehouse you are connecting to is multi-tenanted as described above, you will only need one set of data objects in ThoughtSpot.

Shared content will be filtered per individual user using ThoughtSpot’s data security features, which include several mechanisms for row-level security (RLS).

There are two basic architectures for storing different tenants' data within cloud data warehouses. The following sections describe a best practice starting point for deploying in ThoughtSpot depending on which of the architectures you have chosen for your CDW. REST APIs are available to deploy these patterns at scale. You can create groups, create users, add users to groups, publish content from TML objects, and share that content with the appropriate groups.

Most software development processes involve creating content in a restricted “development” environment, and then once the changes are finished, placing it in a “test” environment. Within a single ThoughtSpot instance, development and test content can be considered as another tenant’s, with access restricted to only app developer users.

For both of the multi-tenancy patterns above, add additional groups for dev and test with only members of your app development team.

Privileges in ThoughtSpot control the set of product features a user has access to. Privileges are assigned to users through groups.

A user’s privilege set is additive based on the groups they belong to; the user at all times has the full set of any privilege from any group they belong to. This is also to say that privileges do not apply only to content shared to the group.

The simplest best practice for assigning privileges to users is to create privilege groups, set to not shareable, with no content shared to them. When configured this way, a privilege group acts as a role definer, and users from any tenant can belong to one of the server-wide privilege groups.

The REST API returns a user’s privilege set as part of the response from the GET /user/ endpoint.

ThoughtSpot groups can be hierarchical; one group can be the parent of another group and so forth. We recommend not to use hierarchical groups in a multi-tenanted situation.

When groups are hierarchical, the rules for how privileges and row-level security are derived become complex. In particular, row-level security is achieved by returning the string value of the names of all groups a user belongs to. Hierarchical groups can vastly inflate the number of group names returned in an RLS query, reducing performance and introducing complexity in auditing.

As mentioned above, you will want to use REST API automation to synchronize the group structures and audit that you have configured them correctly. Another tool for auditing is to create test user accounts — user accounts that belong to the app developer, but are configured as if they are part of a customer organization.

Depending on your internal security policies, you may only want your test user accounts to log in to content attached to test data, rather than production customer data. In this case, you will create a full suite of test content groups simulating at least two “customers”, and test user accounts for each “access level” that exists for the end customer users.

Tags are available in ThoughtSpot to label content and assist in searching. Content can be tagged with multiple tags.

Tags can be used as part of searches using the Metadata REST APIs, with the caveat that it is an inclusive list; the response will include all content with any of the tags sent, as opposed to only including content with the full set of tags.