Users and groups

Table of Contents

User creation and update
- User migration to IAMv2

To provide access to ThoughtSpot content or define privileges, you must add users and groups in ThoughtSpot. You can create user accounts and user groups in the ThoughtSpot UI or via REST API calls.

User creation and update🔗

You can create users and update user profiles using REST API v1 or v2 endpoints.

While you can delete users, it is preferable to deactivate a user, which maintains the user’s references within the system.

When configuring SAML SSO in ThoughtSpot UI, you can select the Automatically add SAML users to ThoughtSpot upon first authentication option, which will use the values in the SAML assertion to create a user if they do not already exist on ThoughtSpot. ThoughtSpot can also add users to groups sent within the SAML assertion. To enable and configure the SAML group attributes, contact your ThoughtSpot team.

By default, ThoughtSpot sends e-mail messages to a new user and enables onboarding workflows when they log in for the first time, even when you are embedding ThoughtSpot content. To alter this behavior at a system-wide level, you need to Customize the onboarding settings. The user update API also allows setting onboarding experience values for an individual user. If you need to modify the default behavior beyond the available UI options, contact your ThoughtSpot team.

Note	ThoughtSpot supports local management of users. For initial development and testing purposes, you can create users in ThoughtSpot and manage their profiles locally. However, in large production environments, avoid creating local user profiles to reduce administration overhead.

User migration to IAMv2🔗

ThoughtSpot is gradually migrating its users to Identity and Access Management v2 (IAMv2) to provide a more secure login and authentication experience through internal authentication with Okta. The following are some of the important points to note with this upgrade:

The email attribute is mandatory when creating a user in ThoughtSpot Okta. ThoughtSpot recommends that users provide a valid email address during user creation.
You must set a password during user creation if you do not want to trigger an activation email.
The default value for usertype will be OIDC_USER.

Administrators can manage the user account status for all users. For IAMv2 users, the API response for the following APIs will also include SUSPENDED as a user state:

To create a user:

POST /api/rest/2.0/users/create (Rest API v2)
POST /tspublic/v1/user (Rest API v1)

To update user details:

POST /api/rest/2.0/users/{user_identifier}/update (Rest API v2)
PUT /tspublic/v1/user/{userid} (Rest API v1)

Note

Updating the username of an SSO user, account_type set to SAML_USER or OIDC_USER, requires changes in both the IdP and ThoughtSpot.

If you rename an SSO user through the REST API and that user then logs in through the IdP:

If Just-in-Time (JIT) provisioning is enabled, ThoughtSpot creates a new duplicate account. The duplicate account does not inherit the original user’s content, groups, or permissions.
If JIT provisioning is disabled, the user cannot log in.

To safely update the username of an SSO user:

Update the username in your IdP.
Before the user logs in again, update the username in ThoughtSpot to match the new value using the REST API or Admin UI.

Both updates must be complete before the user’s next SSO login. The order of the two steps can be reversed — you may update ThoughtSpot first and the IdP second — provided the user does not log in during the interval between the two changes.

For SSO users, ThoughtSpot derives email address and display name directly from the IdP. Update these attributes in your IdP only. ThoughtSpot automatically reflects the new values when the user next logs in through SSO. Do not use the REST API or the Admin UI to update the email address or display name of an SSO user.

Updating the username of an SSO user, account_type set to SAML_USER or OIDC_USER, requires changes in both the IdP and ThoughtSpot.

If you rename an SSO user through the REST API and that user then logs in through the IdP:

If Just-in-Time (JIT) provisioning is enabled, ThoughtSpot creates a new duplicate account. The duplicate account does not inherit the original user’s content, groups, or permissions.
If JIT provisioning is disabled, the user cannot log in.

To safely update the username of an SSO user:

Update the username in your IdP.
Before the user logs in again, update the username in ThoughtSpot to match the new value using the REST API or Admin UI.

For users who authenticate directly with ThoughtSpot (not through an external IdP), you can update username, email address, and display name using the REST API or Admin UI. No IdP coordination is required for local users.

For more information, see the following pages:

== User group creation and update Groups can be created via REST API v2 or REST API v1 API endpoint.

The Group privileges are set directly on groups, either during group creation or via a group update API call.

== User association to groups You can add users to specific groups when creating a user or group via REST API endpoints.

The REST API v1 group/addmemberships endpoint allows adding multiple users to multiple groups in a single request.

To get a list of users assigned to a group, you can use the POST /api/rest/2.0/groups/search v2 endpoint or the /tspublic/v1/group/{groupid}/users v1 endpoint.

To remove a user from a group, use the update group REST v2 endpoint, or the following REST API v1 endpoints:

POST /tspublic/v1/group/{groupid}/user/{userid}
removes a user from a specific group
POST /tspublic/v1/group/removememberships
removes a list of users from many groups at once.

== Access control (sharing) Access to objects is determined by content shared directly to the user or the groups they belong to. It is easier to manage and audit sharing through groups rather than object sharing at the individual user level.

Users can share objects or modify sharing properties through the UI or via an API call to the POST /api/rest/2.0/security/metadata/share or /tspublic/v1/security/share endpoint.

== Group privileges Each user group includes a set of privileges for its users. When a user is assigned to a group in ThoughtSpot, the default privileges associated with a group are assigned to its users. The group privileges allow users belonging to a group to perform specific operations and access workflows. If a user belongs to more than one group, they will have the highest level of privileges from all the groups they belong to.

If a user group belongs to another user group, it inherits privileges from its parent group.

ThoughtSpot administrators can programmatically assign the following types of privileges to a user group:

ADMINISTRATION

Allows users to perform the following functions:
- Create, edit, and delete users and user groups
- View and edit access to all data
- Download a saved answer

DEVELOPER

Allows users to perform the following functions:
- Access Developer portal
- Embed ThoughtSpot app or its content in an external application
- Add custom menu options in the embedded Liveboards and visualizations
- Re-brand the interface elements of the embedded ThoughtSpot content
USERDATAUPLOADING

Allows users to upload data to ThoughtSpot.
DATADOWNLOADING

Allows users to download ThoughtSpot data from search results and Liveboards.
DATAMANAGEMENT

Allows users to create worksheets and views. To edit a worksheet or view created and shared by another user, the user must have edit permission to modify the object.
SHAREWITHALL

Allows users to share objects with other users and user groups.
EXPERIMENTALFEATUREPRIVILEGE

Allows access to the trial and experimental features that ThoughtSpot makes available to evaluating users and early adopters.
JOBSCHEDULING

Allows scheduling and editing Liveboard jobs.
RANALYSIS

Allows invoking R scripts to explore search answers and sharing custom scripts.
A3ANALYSIS

Allows users to generate and access SpotIQ analyses.
BYPASSRLS

Allows access to the following operations:
- Create, edit, or delete existing RLS rules
- Enable or disable Bypass RLS on a worksheet
SYNCMANAGEMENT

Allows setting up secure pipelines to external business apps and sync data using ThoughtSpot Sync.

ThoughtSpot also has a default group called All. When you create new users in ThoughtSpot, they are automatically added to All. By default, the members of the All group do not have permission to download or upload data. To add these privileges, you can use the Group API endpoints.

== Roles If Role-Based Access Control (RBAC) is enabled on your instance, administrators can define role privileges and assign them to users via groups. Roles are always scoped to an Org; a role created in one Org cannot be assigned in another.

=== Assign roles to groups via REST API When creating or updating a group using the REST API v2 endpoints, use the role_identifiers parameter to assign one or more roles to the group. The parameter accepts an array of role GUIDs or role names. For more information, see:

POST /api/rest/2.0/groups/create: include role_identifiers in the request body.
POST /api/rest/2.0/groups/{group_identifier}/update: include role_identifiers to add roles to an existing group.

Roles must be available before they can be assigned. Use the Roles API to create roles programmatically before calling the group create or update endpoints.

For a complete list of available privileges and role categories, see Role-based access control.