ThoughtSpot User Management Guide

• Model type: hybrid
• Description: ThoughtSpot uses a hybrid model combining system-level privileges (assigned via groups) and Roles (a named collection of privileges assignable to users or groups). Roles can be built-in or custom. Object-level sharing (Liveboards, answers, data objects) is managed separately via share permissions (View or Edit). Row-level security is enforced via RLS rules on worksheets.
• Custom roles: Yes
• Custom roles plan: Not documented
• Granularity: System privileges (e.g., Can Manage Data, Can Use Experimental Features), object-level share permissions (View/Edit per object), and row-level security rules on data sources.

1. Log in as an Administrator.
2. Navigate to Admin Console > User Management > Users.
3. Click 'Add User'.
4. Enter the required fields: username, display name, email, and password (for local auth).
5. Optionally assign the user to one or more groups.
6. Optionally assign one or more Roles directly to the user.
7. Click 'Save' to create the user.

Required fields: Username, Display name, Email address, Password (for local authentication; not required if SSO-only)

Watch out for:

• Usernames must be unique across the instance and cannot be changed after creation.
• If SAML/SSO is enforced, the password field may be ignored but is still required in the form for local account creation.
• Users created manually will not be automatically linked to IdP-provisioned accounts unless usernames match exactly.
• Group membership determines inherited privileges; a user with no group assignments has minimal system access.

• Can delete users: Yes
• Delete/deactivate behavior: ThoughtSpot Cloud supports both deleting and deactivating users. Deleting a user permanently removes the account. Deactivating (setting status to 'Inactive') prevents login without removing the account or its associated content. Official docs describe both options in the Users management UI.

1. Navigate to Admin Console > User Management > Users.
2. Locate the user by searching or browsing the list.
3. Click the user's name to open their profile.
4. Change the user's status to 'Inactive'.
5. Save the changes.

Watch out for:

• Deleting a user is irreversible; the account cannot be restored.
• Owned content (Liveboards, answers) should be transferred or documented before deletion to avoid data loss.
• Scheduled Liveboards and alerts owned by the user will cease to run after deactivation or deletion.
• SCIM-provisioned users deprovisioned via IdP are typically deactivated (not deleted) by default per SCIM spec behavior.

• Where to check usage: Admin Console > User Management > Users (view total active user count); detailed usage reporting may be available under Admin Console > Usage Statistics depending on instance configuration.
• How to identify unused seats: ThoughtSpot does not expose a native 'last login date' filter in the standard Users list UI as of available documentation. Admins can use the ThoughtSpot REST API (GET /api/rest/2.0/users/search) to retrieve user metadata including last login timestamps to identify inactive accounts.
• Billing notes: Seats are billed annually based on contracted user count. Deactivating users mid-contract does not automatically reduce billing; seat reductions typically apply at renewal. Enterprise contracts are negotiated directly and may include minimum seat commitments.

ThoughtSpot is an enterprise-tier product with typical annual spend ranging from $100,000 to $500,000 or more depending on user count and data volume. SCIM provisioning is gated to the Enterprise plan, which carries custom pricing negotiated directly. Seats are billed annually on contracted count - deactivating users mid-contract does not reduce billing until renewal.

Implementation professional services are described as expensive and mandatory in available data, adding $50,000–$200,000 to initial deployment cost.

Community evidence is not specific enough to quote or summarize yet for this app.

Manual provisioning is viable for small, stable teams where every app in the stack is managed individually and IdP-based automation is not yet in place.

For any organization with regular onboarding and offboarding volume, the lack of a native last-login UI filter and the risk of orphaned content on deletion make manual-only management operationally expensive at scale.

SCIM on Enterprise eliminates the provisioning overhead but requires SSO to be fully configured first - that prerequisite should be confirmed before planning a SCIM rollout.

Bottom line

ThoughtSpot's manual user management is functional but requires deliberate process design: group membership drives both UI privileges and row-level security, so incorrect assignments have data-exposure consequences, not just access consequences.

The Admin Console covers day-to-day tasks, but auditing inactive users and safely offboarding employees both require API work or strict pre-deletion checklists. Organizations on Enterprise with SSO already in place should prioritize SCIM to reduce the manual surface area;

those on Essentials or Pro should build compensating controls around the gaps the community has documented.