Roles and access in practice
Three roles cover almost every team. Here's what each can do and when to use them.
The roles
| Role | Can do | Can't do |
|---|---|---|
| Owner | Everything (only one per project) | — |
| Editor | Edit pages, run the AI agent, publish, manage team, change settings | Manage billing, transfer ownership, delete the project |
| Viewer (Pro) | See the editor and live preview, read-only | Edit, publish, change settings |
That's it. No "Editor with publish permission only" or "Reviewer who can comment but not edit". Simpler permissions hold up.
Picking the Owner
The Owner is the email Stripe bills. That's it.
- For solo accounts: the Owner is whoever runs Docsio.
- For small teams: make it the team's billing contact (often a founder or ops lead).
- For larger organizations: create a shared billing email (
docs-billing@yourcompany.com) and use that as the Owner. People come and go; shared inboxes don't.
Editors
Most of your team will be Editors. Roles work per-project, so an Editor on Project A doesn't get access to Project B unless explicitly added.
- Add Editors via project settings → Team → Invite member. They get an email link, click it, sign up if needed, and they're in. Pro plans have unlimited Editors at no extra cost.
- Editors can remove other Editors. Be intentional about who you invite — there's no "Editor with limited permissions". If a teammate is going to leave the company in two weeks, wait until they leave.
- Free plans get 0 Editors. It's a solo-only plan.
Viewers (Pro)
Viewers see the editor + live preview but can't change anything. Useful for:
- Reviewers and stakeholders. Lets them see what's coming without giving them the keys.
- Internal customers of the docs (sales engineering, product marketing) who want visibility into what the docs team is shipping.
- External contractors with NDAs who you trust to read but not write.
For visitors who just want to read the published site, Viewer is overkill. They just need the URL.
When to promote
A common pattern: invite as Viewer first, promote to Editor after a project's first publish or two. Two reasons:
- New teammates often need a few days to learn the editor before they're confidently making changes.
- It signals that ownership is earned, not granted.
This is optional, not enforced.
When to demote
Less common. Cases:
- An Editor moves to a role where they no longer maintain docs (engineering → sales). Demote to Viewer or remove.
- Trust issue. Don't tip-toe — remove and discuss.
- The team got too large and you want to reduce who has live access. Be clear it's a process change, not a judgment.
Transferring ownership
When the Owner leaves the company or moves teams: project settings → General → Transfer ownership. Pick another current Editor. The new Owner takes over billing immediately. The previous Owner becomes an Editor automatically.
You can transfer to anyone who's currently an Editor on the project. You can't transfer to someone who isn't on the project — they have to be added as an Editor first.
Removing a teammate
Project settings → Team → click the member → Remove from project. They lose access immediately. They get an email letting them know.
Their commits via GitHub Sync are preserved (those are git history, not Docsio access). Their edits in the version history are preserved. Their access is gone.
For employees being offboarded, remove their Docsio access on the same day as their other systems. The site is publicly readable; their access only matters for editing.