Summary and recommendation
Document360 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.
Document360 is a knowledge base platform with a role-based permission model covering five fixed contributor roles - Owner, Admin, Editor, Draft Writer, and Viewer - plus a separate Reader tier for portal-only access.
There is no custom role builder; permissions are locked to predefined tiers, with optional category-level restrictions layered on top of Editor and Draft Writer roles. Every app in your stack that uses fixed role tiers creates the same ceiling: when your team needs intermediate permissions, you work around the model rather than with it.
Team accounts and Reader accounts consume separate seat quotas, tracked independently under Settings → Users & Security.
Quick facts
| Admin console path | Project Dashboard → Settings → Users & Security → Team Accounts |
| 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 |
|---|---|---|---|---|---|
| Owner | Full control over the project: billing, all settings, user management, content creation and deletion, API key management. Only one Owner per project. | Cannot transfer ownership to another user through self-service UI (requires support involvement). | All plans | Counts as a paid team-account seat | There is only one Owner per project. If the Owner leaves the organization, seat recovery requires contacting Document360 support. |
| Admin | Manage team members, configure project settings, create/edit/publish/delete all content, manage categories, access analytics, configure integrations. | Cannot manage billing or change the Owner. | All plans | Counts as a paid team-account seat | Admins can invite and remove other team members including other Admins, which can create accidental lockout scenarios if the Owner is inactive. |
| Editor | Create, edit, and publish articles; manage categories they have access to; view analytics. | Cannot manage team members, configure project-level settings, or access billing. | All plans | Counts as a paid team-account seat | |
| Draft Writer | Create and edit draft articles; submit drafts for review. Cannot publish directly. | Cannot publish articles, manage categories, manage users, or access project settings. | All plans | Counts as a paid team-account seat | Draft Writers require an Editor or Admin to review and publish their work; no self-publish capability. |
| Viewer (Team) | Read-only access to the internal project workspace and draft content. Cannot create or edit content. | Cannot create, edit, or publish content; cannot manage users or settings. | All plans | Counts as a paid team-account seat | Team Viewers are distinct from Reader (portal) accounts; both consume seats under their respective quotas. |
| Reader (Portal User) | Access to the published knowledge base portal (public or private). Can view articles they are permitted to see based on reader group assignments. | Cannot access the authoring/back-end workspace, create or edit content, or manage any settings. | Private knowledge base / reader access requires Business plan or higher | Reader seats are tracked separately from team-account seats; quota depends on plan tier | Reader accounts are managed under a separate section (Readers) from team accounts. Reader seat limits vary by plan and are separate from contributor seat limits. |
Permission model
- Model type: role-based
- Description: Document360 uses a fixed set of built-in roles for team (contributor) accounts: Owner, Admin, Editor, Draft Writer, and Viewer. Roles are assigned per project. There is no custom role builder; permissions are tied to the predefined role tiers. Category-level access restrictions can be applied on top of roles for Editors and Draft Writers, providing some granularity below the role level.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level permissions are fixed. Category-level visibility/access restrictions can be layered on top of Editor and Draft Writer roles. No field-level or article-level permission granularity beyond category access.
How to add users
- Log in to the Document360 portal at app.document360.io.
- Navigate to Settings → Users & Security → Team Accounts.
- Click 'Invite Team Member'.
- Enter the invitee's email address.
- Select the appropriate role (Admin, Editor, Draft Writer, or Viewer).
- Optionally restrict category access if the role is Editor or Draft Writer.
- Click 'Send Invite'. The invitee receives an email invitation to join the project.
Required fields: Email address, Role selection
Watch out for:
- Invitations expire; if the invitee does not accept within the expiry window, a new invitation must be sent.
- The invitee must create a Document360 account (or log in via SSO) to accept the invitation.
- Adding a team member consumes a seat against the plan's team-account quota. Exceeding the quota requires a plan upgrade.
- SSO auto-registration (if configured) can automatically create team accounts when users authenticate via IDP, which may consume seats without explicit admin action.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Business or Enterprise (SSO required; SAML/OIDC auto-registration provisions accounts on first login) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Document360 allows removing (deleting) a team member from a project. The removed user loses access to the project immediately. Content authored by the removed user is retained in the project and is not deleted. There is no documented 'deactivate' (suspend without removal) state for team accounts; removal is the primary offboarding action.
- Log in to app.document360.io.
- Navigate to Settings → Users & Security → Team Accounts.
- Locate the team member to remove.
- Click the options menu (three dots or similar) next to the user.
- Select 'Remove' or 'Delete' to revoke their project access.
- Confirm the removal when prompted.
| Data impact | Behavior |
|---|---|
| Owned records | Articles and content created by the removed user remain in the project and are not deleted. Authorship attribution is preserved in version history. |
| Shared content | Shared categories and articles remain accessible to other team members with appropriate permissions. |
| Integrations | Any API keys or tokens associated with the removed user's account should be reviewed and revoked separately; removal from the project does not automatically invalidate personal API tokens. |
| License freed | Removing a team member frees up one seat against the plan's team-account quota, making it available for a new invitation. |
Watch out for:
- There is no 'suspend' or 'deactivate' state; removal is permanent for that project. The user can be re-invited later.
- If the removed user was the sole Admin (and not the Owner), the Owner must reassign admin duties before or after removal.
- The Owner account cannot be removed by other Admins; only the Owner can transfer or relinquish ownership.
- SSO-provisioned users who are removed from the project can still authenticate via SSO; auto-registration settings may re-create their account on next login if not also disabled in the IDP.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Team Account seat (contributor) | One named user with a role of Owner, Admin, Editor, Draft Writer, or Viewer in the authoring workspace. | Included up to plan quota; additional seats require plan upgrade or add-on (custom pricing, no public per-seat rate published). |
| Reader seat (portal user) | One named reader account with access to the private knowledge base portal. | Quota included per plan tier; additional reader seats available via plan upgrade (custom pricing). |
- Where to check usage: Settings → Users & Security → Team Accounts (shows current team member count vs. plan quota); Settings → Users & Security → Readers (shows reader account count vs. quota).
- How to identify unused seats: No built-in 'last login' or activity report is prominently documented for team accounts in the help center. Admins must manually review the team member list and cross-reference with known activity. Reader account last-access data may be available in analytics depending on plan tier.
- Billing notes: Document360 uses custom pricing with no publicly listed per-seat rates. Plan quotas for team accounts and reader accounts differ by tier. Exceeding seat quotas requires contacting Document360 sales for an upgrade. The 14-day free trial includes full feature access. A startup program offers 6 months free on Business/Enterprise plans followed by 50% off for 6 months.
The cost of manual management
Document360 uses custom pricing with no publicly listed per-seat rates, so seat costs are opaque until you engage sales. SSO auto-registration compounds this: new users authenticating via your IdP can be created without explicit admin approval, consuming quota without a visible trigger.
There is no built-in last-login or activity report for team accounts, so identifying unused seats requires manually cross-referencing the member list against known activity.
What IT admins are saying
The most consistent friction reported by Document360 admins centers on three gaps.
First, the absence of a suspend or deactivate state means offboarding a contractor or employee on leave requires full removal - there is no way to freeze access temporarily without losing the user record.
Second, SSO auto-registration silently creates team accounts on first IdP login, which surprises admins when seat counts rise unexpectedly. Third, there is no bulk CSV import for team members, making large-scale onboarding a one-invite-at-a-time process.
Common complaints:
- Users report that there is no granular custom role builder; permissions are locked to the five predefined roles, which can be too coarse for larger teams needing intermediate permission levels.
- The lack of a 'suspend/deactivate' state (as opposed to full removal) is noted as a gap when temporarily offboarding contractors or employees on leave.
- SSO auto-registration can silently consume team-account seats when new users authenticate via IDP without explicit admin approval, leading to unexpected seat overages.
- No bulk CSV import for team members is available, making large-scale onboarding manual and time-consuming.
- Pricing opacity (no public per-seat rates) makes it difficult to forecast costs when scaling team size.
- Reader seat limits and team-account seat limits are tracked separately, causing confusion about which quota applies when adding different user types.
The decision
Manual management is workable for small, stable teams where the contributor roster changes infrequently. The five-role model covers most knowledge base team structures, and category-level restrictions add enough granularity for most editorial workflows.
The calculus shifts when your team scales or turns over contractors regularly - every app without automated deprovisioning demands the same manual discipline, and Document360's lack of a suspend state and activity reporting makes it harder than most to maintain a clean, auditable access record without dedicated operational overhead.
Bottom line
Document360's manual user management is straightforward for day-to-day adds and removes, but the combination of opaque custom pricing, no suspend state, no bulk import, and silent SSO seat creation creates compounding overhead as team size or turnover increases.
Every app without automated provisioning demands the same manual discipline; Document360 is no exception, and the lack of a last-login signal makes it harder than most to catch access drift before it becomes a billing or security issue.
Automate Document360 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.
