Summary and recommendation
Sana Labs 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.
Sana Labs is an AI-powered learning platform with role-based access control covering at minimum learner and admin roles.
Manual user management is available, but granular role configuration details are not publicly documented.
SCIM provisioning the recommended path for automating access at scale is gated behind the Enterprise plan, meaning every app dependency in your provisioning workflow has to account for this tier restriction.
Quick facts
| Admin console path | Settings / Administration > Users and Roles (exact labels vary by tenant) |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Can manage tenant settings, integrations, and user access. | Cannot grant functionality outside the modules licensed for the tenant. | Detailed built-in role names are not fully documented publicly. | ||
| Standard User | Can use the core product features exposed to their role. | May not be able to manage tenant settings or other users. | Exact privileges can vary by tenant configuration. |
Permission model
- Model type: role-based
- Description: Sana Labs appears to use role-based access for tenant administration and general product use, but the detailed permission matrix is not publicly documented in full.
- Custom roles: Unknown
- Custom roles plan: Not documented
- Granularity: Expect administrative access to be separated from standard user access, with exact scopes configured per tenant.
How to add users
- Log in as an administrator.
- Open settings or administration and navigate to users.
- Choose the add or invite user action.
- Enter the user's work email and assign the appropriate role.
- Save the user and complete any activation or SSO steps required by the tenant.
Required fields: Work email address, Role
Watch out for:
- Public documentation for user administration is limited, so exact labels may vary by tenant.
- If SSO is enabled, upstream IdP assignment may still be required.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Public docs do not clearly document whether users are disabled, deleted, or both. Treat lifecycle behavior as tenant-specific unless confirmed in-product.
- Open the users area as an administrator.
- Locate the user to offboard.
- Disable, revoke, or remove the account using the controls available in that tenant.
- Review any integrations or service credentials associated with the departing user.
| Data impact | Behavior |
|---|---|
| Owned records | Tenant data remains in the workspace; public docs do not describe user-owned content semantics in detail. |
| Shared content | Shared dashboards, configurations, and records remain available unless separately removed. |
| Integrations | Review service credentials and integration ownership separately during admin offboarding. |
| License freed | Seat reuse behavior is contract-dependent and not publicly documented in detail. |
Watch out for:
- Offboarding should include token and integration review, not just interactive login removal.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Core seat | Full learner and admin access on Core plan; minimum 300 users required. | $13/user/mo (billed annually, min 300 users) |
| Enterprise seat | Custom pricing; includes SCIM provisioning and advanced admin features. | Custom |
- Where to check usage: Settings / Administration > Users and Roles
- How to identify unused seats: Review the tenant user list and any visible login or activity metadata. No public unused-seat report was verified.
- Billing notes: Core plan requires a minimum of 300 seats. Enterprise pricing is negotiated directly with Sana Labs. No self-serve seat reduction details are publicly documented.
The cost of manual management
Without automation, every app in your stack that touches employee learning access requires a separate manual action when someone joins, moves teams, or leaves. Sana's Core plan starts at $13/user/mo with a 300-seat minimum, and SCIM is not included at that tier.
That means any org on Core is managing provisioning and deprovisioning by hand, with no documented self-serve seat reduction path to recover spend when headcount drops.
The decision
If your org is on the Core plan, manual provisioning is your only option - and the admin workflows for adding or removing users are not publicly documented outside of authenticated help sessions. Every app you manage without automation adds compounding offboarding risk, and Sana is no exception.
Enterprise customers can unlock SCIM, but that requires a custom pricing negotiation with Sana directly.
Bottom line
Sana Labs works well as a learning platform, but its access management story has real gaps for teams below Enterprise tier. Every app you manage manually adds offboarding risk and wasted seat spend - and Sana's Core plan offers no documented automation path.
If provisioning hygiene matters to your org, budget for Enterprise or plan to own the manual overhead explicitly.
Automate Sana Labs 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.
