Summary and recommendation
Khoros 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.
Khoros Community uses a hybrid permission model that combines predefined system roles (Administrator, Moderator, Member) with custom roles built from granular permission sets. Permissions can be scoped globally or down to individual boards, categories, and groups.
A rank-based privilege escalation layer for community members adds complexity that can produce unintended access if roles and ranks are not configured in tandem.
There is no native SCIM support. User provisioning relies on JIT (Just-in-Time) via SAML SSO for Enterprise-tier customers, or on manual creation through the Community Admin panel at Admin > Users > All Members.
For every app that feeds identity into Khoros, the IdP remains the authoritative source - disabling access there is the only reliable way to prevent JIT re-provisioning after a ban.
Quick facts
| Admin console path | Admin > Users (for Khoros Community: Community Admin panel, typically accessed via your-community-domain.com/t5/admin/) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full access to Community Admin panel; can manage all settings, users, roles, content, and integrations | Cannot exceed permissions granted by the platform license tier; some advanced features (e.g., API access, SSO config) may require Enterprise tier | Any paid tier | Custom pricing; no published per-seat rate | Administrator role is distinct from the community 'Super Admin' account created at provisioning; only one Super Admin account exists per community instance |
| Moderator | Can moderate content (approve, reject, move posts), manage member accounts within assigned boards or categories, issue warnings/bans | Cannot access full Admin panel settings; cannot modify global roles or platform configuration | Any paid tier | Custom pricing; no published per-seat rate | Moderator permissions are scoped per board/category; a moderator of one board does not automatically have rights on another |
| Community Member (Registered User) | Can post, reply, like, and participate in community areas permitted by their rank/role; can manage their own profile | Cannot access Admin panel; cannot moderate others' content unless promoted | No additional cost; end-user community members are typically not counted as paid seats | Not a paid seat in standard licensing; volume of community members may affect tier pricing indirectly | Member permissions are controlled by a combination of role assignment and rank-based privilege escalation; these interact and can produce unexpected access if not configured carefully |
| Custom Role | Configurable subset of permissions drawn from the platform's permission set; can be scoped to specific boards, categories, or the entire community | Cannot exceed the permissions of the Administrator role; cannot grant permissions the assigning admin does not themselves hold | Available on paid tiers; full custom role granularity may require Enterprise | Custom pricing | Custom roles must be explicitly assigned per user; they are not inherited automatically |
Permission model
- Model type: hybrid
- Description: Khoros Community uses a hybrid model combining predefined system roles (Administrator, Moderator, Member) with custom roles that can be built from granular permission sets. Permissions can be scoped globally or to specific nodes (boards, categories, groups). Rank-based privilege escalation for community members adds a gamification layer that can also affect functional permissions.
- Custom roles: Yes
- Custom roles plan: Paid tiers; full granularity confirmed on Enterprise; availability on lower tiers not explicitly documented
- Granularity: Node-level (board, category, group) and action-level (post, reply, moderate, delete, move, ban, etc.)
How to add users
- Log in to the Community Admin panel at https://
/t5/admin/ - Navigate to Users > All Members (or Users > Manage Members depending on version)
- To invite or create a user manually, use the 'Add Member' or 'Invite Member' option if available in your tier
- Enter required fields (email address, username)
- Assign a role if the user requires elevated permissions beyond standard Member
- Save; the user receives an email invitation to set their password (for non-SSO communities)
Required fields: Email address, Username
Watch out for:
- For SSO-enabled communities, users are typically provisioned automatically via JIT (Just-In-Time) on first login; manual creation may be bypassed or conflict with SSO records
- The ability to manually create admin/staff accounts may be restricted depending on SSO configuration - SSO-enforced communities may require all accounts to originate from the IdP
- Khoros does not support SCIM provisioning natively; bulk automated provisioning relies on SSO JIT or API-based approaches
- Username changes after account creation can cause content attribution issues
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (SSO/JIT provisioning via SAML, OAuth2, or OIDC; requires SSO configuration which is an Enterprise-tier feature) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Khoros Community supports both banning/deactivating a member account and deleting a member account. Deletion is available to Administrators from the member management panel. Banning prevents login and participation while preserving the account record and content. Deletion removes the account but content handling (reassignment vs. deletion) depends on configuration. Permanent deletion of community-contributed content is generally discouraged due to content integrity concerns.
- Navigate to Admin > Users > All Members
- Search for the target user by username or email
- Open the user's profile in the Admin panel
- Select 'Ban Member' to deactivate/suspend the account, or 'Delete Member' to permanently remove it
- If banning, choose ban duration (temporary or permanent) and optionally provide a reason
- Confirm the action
| Data impact | Behavior |
|---|---|
| Owned records | Posts, replies, and other content created by the user remain in the community by default after ban or deletion; content is not automatically removed |
| Shared content | Shared or co-authored content remains visible; attribution may show the original username or be anonymized depending on deletion settings |
| Integrations | API tokens or integration credentials tied to the user account may need to be manually revoked separately |
| License freed | For community member accounts, no paid seat is typically consumed, so deactivation does not free a billable license. For staff/admin accounts on paid seat models, deactivation or deletion should free the seat, but this must be confirmed with Khoros account management given custom pricing. |
Watch out for:
- Banning a user in an SSO-enabled community does not revoke their IdP session or prevent re-provisioning via JIT on next SSO login unless the IdP account is also disabled
- Deleted accounts cannot be recovered; content orphaned by deletion may display with a generic 'deleted user' attribution
- There is no bulk deactivation tool documented in the standard Admin UI; bulk actions require API usage
- If a banned user's email is reused for a new account, conflicts may arise depending on community configuration
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Community Platform License | Access to Khoros Community platform for a defined number of admin/staff users; unlimited registered community members are typically not counted as seats | Custom pricing; Enterprise contracts typically start at ~$20K/year and can exceed $200K/year depending on scale and features |
| Khoros Care / Social Engagement Agent Seat | For Khoros Care (social customer service product): per-agent seat licensing for agents handling social/community interactions | Custom pricing; separate from Community platform licensing |
- Where to check usage: Admin > Users > All Members (for community member counts); specific license seat usage reporting is managed through Khoros account management / customer success, not self-serve in the Admin UI
- How to identify unused seats: No documented self-serve tool for identifying unused admin/staff seats. Customer must work with Khoros account management or use the Users list in Admin to audit last-login dates if available.
- Billing notes: Pricing is fully custom and contract-based. 90-day renewal notice is required per standard contract terms. Seat counts and feature access are negotiated at contract time. Community member volume (MAU or registered users) may factor into pricing tiers. No public pricing page.
The cost of manual management
Bulk user operations are not available in the standard Admin UI; any bulk deactivation or export requires API access or a support ticket. Admins working in large communities report that the member management interface lacks the filtering and sorting needed to audit access at scale.
License and seat consumption is opaque - there is no self-serve dashboard showing contracted limits versus current usage. Customers must work through Khoros account management to reconcile seat counts, and the 90-day renewal notice requirement means delayed audits carry real contract risk.
Banning a user does not revoke their IdP session. If the corresponding IdP account stays active, the user can re-authenticate via SSO and JIT provisioning may create a new community account, effectively bypassing the ban.
What IT admins are saying
Admins consistently flag the SSO/ban gap as the most operationally dangerous issue: banning in Khoros without disabling the IdP account leaves the door open for immediate re-entry via JIT. This is not a configuration edge case - it affects every SSO-enabled community.
The interaction between custom roles and rank-based privileges is reported as poorly documented, leading to unintended permission grants that are difficult to audit after the fact. Custom roles must be explicitly assigned per user and are not inherited automatically.
Support response times for provisioning and account issues are cited as slow, and some administrative actions require opening a support ticket rather than being self-serve - a meaningful operational cost for teams managing frequent onboarding or offboarding cycles.
Common complaints:
- Admins report that banning a user in Khoros Community does not prevent re-entry if SSO/JIT is active and the IdP account remains enabled - the user can simply log in again via SSO and a new account may be created
- Users report difficulty finding a straightforward bulk user management or bulk deactivation tool in the Admin UI; most bulk operations require API access
- Admins note that the permission model interaction between custom roles and rank-based privileges is complex and not well-documented, leading to unintended access grants
- Community managers report that the Admin panel UI for user management is not intuitive and lacks filtering/sorting capabilities needed for large communities
- Customers report that license and seat management is opaque - there is no self-serve dashboard showing current seat consumption vs. contracted limit
- Some admins note that Khoros support response times for account/provisioning issues can be slow, and that critical user management changes sometimes require a support ticket rather than being self-serve
The decision
Khoros is appropriate for organizations that already operate an Enterprise SSO stack and can accept JIT as the primary provisioning mechanism. Teams that need deterministic, automated lifecycle management for every app in their stack will find the absence of SCIM and bulk UI tooling a persistent gap.
Manual administration is workable for small, stable communities but does not scale cleanly. The opaque licensing model and 90-day renewal notice requirement favor organizations with dedicated vendor management capacity.
If your offboarding process requires guaranteed, immediate access revocation, the IdP must be treated as the control plane - Khoros-side banning alone is not sufficient.
Bottom line
Khoros Community's manual user management is functional but operationally demanding at scale. The absence of SCIM, the lack of bulk UI tooling, and the SSO/ban re-provisioning gap mean that reliable lifecycle management requires disciplined IdP hygiene and, for anything beyond small communities, API-based automation.
License visibility is contract-managed rather than self-serve, which adds overhead to renewal and audit cycles. Teams evaluating Khoros should plan for the IdP to own the authoritative access state and treat the Community Admin panel as a secondary enforcement layer.
Automate Khoros 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.
