Summary and recommendation
Sprinklr user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Sprinklr user management lives at Settings → Users & Permissions → Users.
The platform supports three user types - Admin, Standard User, and Custom Role - with permissions scoped at both the module level and the workspace level.
Because Sprinklr is an Enterprise-only platform, every app configuration, role structure, and seat count is negotiated at contract time rather than self-served through a pricing page.
Quick facts
| Admin console path | Settings → Users & Permissions → Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full access to all platform settings, user management, workspace configuration, integrations, and billing-related settings. Can create and assign roles, manage all users. | Custom / included in platform license | Admin role count may be limited by contract; confirm with Sprinklr account team. | ||
| Standard User | Access to modules and features as defined by the role and permission set assigned by an Admin. Typical access includes publishing, engagement, reporting depending on assigned permissions. | Cannot access Settings or manage other users unless explicitly granted. | Custom / per-seat licensing negotiated at contract | Permissions are additive via permission sets; users with no role assigned may have no functional access. | |
| Custom Role | Granular permissions configured by Admin across modules (e.g., Publish, Engage, Listen, Analyze). Scope can be restricted to specific workspaces or accounts. | Cannot exceed permissions of the Admin who created the role. | Enterprise | Custom | Custom roles are workspace-scoped; a user may need separate role assignments per workspace. |
Permission model
- Model type: hybrid
- Description: Sprinklr uses a combination of predefined system roles and custom roles built from granular permission sets. Permissions can be scoped at the workspace level, allowing different access levels across different business units or brands within the same account.
- Custom roles: Yes
- Custom roles plan: Enterprise
- Granularity: Module-level and action-level (e.g., create, edit, delete, approve) within each Sprinklr product pillar (Publish, Engage, Listen, Analyze, Care). Workspace-scoped assignments supported.
How to add users
- Navigate to Settings → Users & Permissions → Users.
- Click 'Invite User' or 'Add User'.
- Enter the user's email address.
- Assign a Role from the available system or custom roles.
- Select the applicable Workspace(s) the user should access.
- Optionally assign specific Permission Sets.
- Click 'Send Invite' or 'Save'. The user receives an email invitation to set up their account.
Required fields: Email address, Role, Workspace assignment
Watch out for:
- Users must accept the email invitation before they can log in; pending invitations count against seat limits in some configurations.
- Workspace assignment is required; a user without a workspace assignment will have no access to content.
- SSO-enforced environments may require the user's email domain to match the configured IdP before the invite can be accepted.
- Role assignment is workspace-specific; the same user may need separate role assignments if they need access to multiple workspaces.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Settings → Users & Permissions → Users → Bulk Import (CSV upload option) |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Sprinklr help documentation focuses on deactivation in the admin UI. Public API documentation also exposes delete-style user operations, so tenant-specific lifecycle behavior should be validated before assuming deactivation is the only path.
- Navigate to Settings → Users & Permissions → Users.
- Locate the user using search or filters.
- Click the user's name or the action menu (three-dot icon) next to their record.
- Select 'Deactivate User'.
- Confirm the deactivation in the dialog prompt.
| Data impact | Behavior |
|---|---|
| Owned records | Content, posts, and cases created by the deactivated user remain in the platform and are accessible to Admins and other users with appropriate permissions. |
| Shared content | Shared assets, reports, and dashboards created by the deactivated user remain accessible to collaborators. |
| Integrations | API tokens or integrations tied to the deactivated user's account may stop functioning; Admins should reassign or regenerate tokens before deactivation. |
| License freed | Deactivating a user frees the seat for reassignment; the exact timing of seat release depends on contract terms and should be confirmed with the Sprinklr account team. |
Watch out for:
- Deactivated users can be reactivated by an Admin; reactivation restores prior role and workspace assignments.
- If SCIM provisioning is active, user deactivation should be managed from the IdP to avoid sync conflicts.
- Admins should audit and reassign any approval workflows or content queues owned by the user before deactivating to avoid process disruption.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named User Seat | Access to licensed Sprinklr product modules as defined in the contract (e.g., Social, Service, Marketing). Seat is tied to a specific user email. | Custom; negotiated per contract based on modules and user count. |
- Where to check usage: Settings → Users & Permissions → Users (filter by Active status to view current active seat consumption)
- How to identify unused seats: Filter the Users list by 'Last Login' date to identify users who have not logged in recently. Sprinklr does not natively surface an 'unused seat' report in all configurations; Admins may need to export the user list and sort by last activity.
- Billing notes: Sprinklr uses custom enterprise pricing; seat counts and module access are defined at contract time. Changes to seat counts typically require a contract amendment. Deactivating users frees seats but billing adjustments are subject to contract terms.
The cost of manual management
Sprinklr does not surface an inactive-user or unused-seat report natively in all configurations. Admins must export the full user list and sort by Last Login date to identify candidates for deactivation. Role changes may not take effect until the affected user logs out and back in, adding friction to every app access correction made mid-cycle.
Workspace assignments are required per user and per workspace, meaning a single employee needing access to multiple business units requires separate role assignments for each - multiplying the administrative overhead as headcount grows.
The decision
Manual management is viable for small, stable teams where workspace structure rarely changes. It becomes a liability at scale: every app offboarding requires a manual deactivation workflow, seat audits require CSV exports, and multi-workspace environments multiply role assignment work linearly with headcount.
Teams on the Enterprise plan with an active IdP should evaluate SCIM provisioning to eliminate the manual loop - but SSO must be fully live before SCIM can be enabled, and role assignment still requires separate handling even after SCIM is configured.
Bottom line
Sprinklr's manual user management is functional but labor-intensive for any team managing more than a handful of users across multiple workspaces. The lack of a native inactive-user report means license hygiene depends entirely on admin discipline and periodic CSV audits.
For Enterprise customers with an established IdP, the operational cost of staying manual compounds quickly - every app addition, role change, and offboarding event requires deliberate, multi-step action with no automated safety net.
Automate Sprinklr workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
