Summary and recommendation
Stonly 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.
Stonly is a role-based interactive knowledge base platform.
Every app in your stack that touches onboarding, support, or internal documentation is a candidate for Stonly access, and provisioning is handled entirely through the Settings → Team console.
Three predefined roles exist - Admin, Editor, and Viewer - with no documented support for custom roles at any plan tier.
Quick facts
| Admin console path | Settings → Team |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full workspace access: manage billing, invite/remove members, configure SSO, manage all guides and knowledge bases, access all settings. | ||||
| Editor | Create, edit, and publish guides and knowledge bases. Cannot access billing or workspace-level settings. | Cannot manage team members, billing, or workspace settings. | |||
| Viewer | Read-only access to guides and knowledge bases within the workspace. | Cannot create, edit, or publish content. Cannot manage team or settings. |
Permission model
- Model type: role-based
- Description: Stonly uses a role-based permission model with predefined roles assigned per workspace member. Custom roles are not documented in official sources.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level only; no documented per-object or per-guide granular permissions.
How to add users
- Navigate to Settings → Team in the Stonly app.
- Click 'Invite member' or equivalent invite button.
- Enter the invitee's email address.
- Select the role to assign (Admin, Editor, or Viewer).
- Send the invitation. The invitee receives an email to accept and join the workspace.
Required fields: Email address, Role
Watch out for:
- Free plan is limited to 1 user; additional seats require a paid plan.
- Invitations may expire if not accepted within a set period.
- SSO-based provisioning is only available on the Enterprise plan.
| 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: Official documentation does not explicitly distinguish between deactivation and deletion of team members. The remove/delete behavior is not clearly documented in publicly available official sources.
- Navigate to Settings → Team.
- Locate the team member to remove.
- Select the option to remove or revoke access for that member.
| Data impact | Behavior |
|---|---|
| Owned records | Not documented |
| Shared content | Not documented |
| Integrations | Not documented |
| License freed | Not documented |
Watch out for:
- Official documentation does not clearly state what happens to content owned by a removed user.
- Seat/license release behavior upon removal is not explicitly documented in publicly available sources.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named user seat | Access to Stonly workspace as Admin, Editor, or Viewer depending on assigned role. | Included in plan; Free plan allows 1 user, paid plans allow additional seats per plan tier. |
- Where to check usage: Settings → Team (shows current members and seat usage)
- How to identify unused seats: Not documented
- Billing notes: Free plan: 1 user. Starter ($124/month) and Small Business ($249/month, $199/month annual) plans include additional seats. Enterprise plan pricing is custom. Seat limits per plan are not fully enumerated in publicly available pricing documentation.
The cost of manual management
Adding a user requires navigating to Settings → Team, clicking the invite button, entering an email address, and selecting a role.
Removing a user follows the same path, though official documentation does not clearly state what happens to content owned by a removed member, and seat-release behavior on removal is not explicitly confirmed in any public source.
Every app with this level of documentation gap creates operational risk: offboarding ambiguity means you cannot confirm access is fully revoked without manual verification.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Stonly suits teams that need a lightweight, role-gated knowledge base and are comfortable with manual provisioning. The absence of SCIM and the Enterprise-only SSO gate mean that automated lifecycle management is not available below the Enterprise tier, and even at Enterprise, SCIM support is unconfirmed in public documentation.
Teams with strict joiner/mover/leaver compliance requirements should verify provisioning capabilities directly with Stonly before committing.
Bottom line
Stonly's manual provisioning workflow is straightforward for small, stable teams but does not scale cleanly for organizations that need automated onboarding or auditable offboarding.
SSO is gated to the Enterprise plan, SCIM is unconfirmed at any tier, and the remove-user flow lacks documented clarity on content ownership and seat release.
Until Stonly publishes explicit lifecycle documentation, every app access review for Stonly will require manual headcount reconciliation against the Settings → Team roster.
Automate Stonly 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.
