Sourcegraph User Management Guide

• Model type: hybrid
• Description: Sourcegraph uses a hybrid model: a flat role system (Site Admin vs. User) for instance-level access, combined with optional RBAC custom roles for feature-level permissions on Enterprise, and code-host-mirrored repository permissions for data access control.
• Custom roles: Yes
• Custom roles plan: Enterprise
• Granularity: Feature-level (Batch Changes, Cody, ownership) and repository-level (mirrored from code host). Instance-level admin is binary (admin or not).

1. Sign in as a site admin.
2. Navigate to Site Admin → Users & Auth → Users (URL: /site-admin/users).
3. Click 'Create user account'.
4. Enter the username and email address.
5. Optionally set a password or leave blank to send an email invitation.
6. Click 'Create account'. The user receives an email to set their password if no password was set.

Required fields: Username, Email address

Watch out for:

• If the instance uses SSO (SAML/OIDC) as the primary auth provider, manually created accounts may conflict with SSO-provisioned accounts unless the email matches exactly.
• Email delivery must be configured on the instance (SMTP settings) for invitation emails to send.
• Usernames must be unique and follow Sourcegraph's username format (alphanumeric, hyphens, dots); spaces are not allowed.
• Manually created users still consume a licensed seat immediately upon creation, even before first login.

• Can delete users: Yes
• Delete/deactivate behavior: Sourcegraph supports both deactivation (soft disable) and hard deletion. Deactivation prevents login and frees the seat while preserving user data. Hard deletion permanently removes the user account and associated data (saved searches, settings). Hard delete is available via the site-admin Users panel or the GraphQL API.

1. Sign in as a site admin.
2. Navigate to Site Admin → Users & Auth → Users (/site-admin/users).
3. Locate the user by searching their username or email.
4. Click the user's name to open their profile.
5. Click 'Deactivate user' to disable login without deleting data, or 'Delete user' for permanent removal.
6. Confirm the action in the dialog.

Watch out for:

• Hard deletion is irreversible; Sourcegraph does not provide a restore mechanism for deleted users.
• If SCIM provisioning is active, deprovisioning the user in the IdP will automatically deactivate (not hard-delete) the Sourcegraph account; manual hard deletion must still be done in Sourcegraph if required.
• Deactivated users still appear in the user list with a 'Deactivated' badge; they must be filtered out manually when auditing active seat usage.
• Site admins cannot deactivate their own account; another site admin must perform the action.

• Where to check usage: Site Admin → Licensing (/site-admin/license) shows total licensed seats, seats in use, and license expiry. Site Admin → Users (/site-admin/users) shows all active and deactivated accounts.
• How to identify unused seats: Navigate to Site Admin → Users (/site-admin/users) and sort or filter by 'Last active' date to identify users who have not logged in recently. There is no built-in automated idle-user report; admins must manually review last-active timestamps.
• Billing notes: Seat count is based on active (non-deactivated) user accounts at the time of billing. Deactivating a user reduces the active seat count. License keys are applied at Site Admin → Licensing; exceeding the licensed seat count triggers a warning but does not immediately lock out users on self-hosted instances.

Adding a user manually takes six steps: sign in as site admin, navigate to /site-admin/users, click 'Create user account', enter username and email, optionally set a password, and confirm. The seat is consumed immediately on creation, before the user ever logs in.

If your instance uses SSO as the primary auth provider, manually created accounts must have an email that matches exactly what the IdP will assert, or you risk duplicate account conflicts. SMTP must be configured for invitation emails to reach the new user at all.

Removing a user is either a soft deactivation (login blocked, seat freed, data preserved) or a hard delete (permanent, no restore path). Hard deletion orphans any shared content - notebooks, code insights - with no reassignment workflow.

If SCIM is active, the IdP handles deactivation automatically via PATCH active: false, but hard deletion still requires a manual action inside Sourcegraph.

There is no built-in idle-user report. Identifying unused seats means manually sorting the Users list by 'Last active' date - a recurring audit task with no automation unless you script it against the GraphQL API.

Practitioners flag a consistent set of friction points with Sourcegraph's user management. SCIM support is officially tested only against Okta and Entra ID; any other IdP requires manual workarounds with no documented path.

Entra ID's SCIM validator in particular surfaces edge-case errors during initial setup that are not well-explained in official docs.

Bulk user creation has no native CSV import path. Teams that need to onboard large cohorts outside of SCIM must script against the GraphQL API or create accounts one at a time.

The absence of automated idle-user detection is a recurring complaint for license-conscious admins who need to reclaim seats without building their own tooling.

Common complaints:

• Limited to tested IdPs (Okta, Entra ID) for SCIM; other IdPs require manual workarounds.
• Azure AD (Entra ID) SCIM validator issues can cause confusion during initial setup.
• No built-in CSV import for bulk user creation; bulk provisioning requires SCIM or manual API scripting.
• No automated idle-user detection or reporting; admins must manually audit last-active timestamps to reclaim seats.
• Hard deletion of users can orphan shared content (notebooks, insights) with no reassignment workflow.
• Domain-based allow-listing (auto-provisioning users from a trusted email domain) behavior depends on auth provider configuration and is not a simple toggle in all setups.
• Network requirements for private/air-gapped deployments add complexity to SCIM and SSO configuration.

Manual management is workable for small teams or one-off changes, but it does not scale cleanly. Every app your team uses benefits from a consistent offboarding process; Sourcegraph's lack of automated idle detection and no-restore hard-delete behavior make discipline around deprovisioning especially important here.

If your organization is already on Enterprise with Okta or Entra ID, SCIM provisioning eliminates the manual overhead and keeps seat counts accurate automatically. Teams on Enterprise Starter should plan for manual or API-scripted provisioning, since SCIM is not available at that tier.

Custom RBAC roles are also Enterprise-only, so feature-level permission scoping is not an option below that plan.

Bottom line

Sourcegraph's manual user management is straightforward for day-to-day adds and removes but carries real operational cost at scale: no idle-user automation, no bulk import, and a hard-delete that is irreversible with no content reassignment.

Teams on Enterprise with Okta or Entra ID should prioritize SCIM setup to keep provisioning consistent and seat counts accurate.

Everyone else should build a recurring audit habit around the Last Active filter in the Users panel, and treat hard deletion as a deliberate, high-stakes action rather than a routine offboarding step.