Concepts
Workspaces and roles
How ProductOS organizes teams, what each role can do, and how to invite people without breaking the Golden Thread.
A workspace is the unit of isolation in ProductOS. Every piece of data (feedback, themes, features, integrations, API tokens) belongs to exactly one workspace. Workspaces never share data. Your team has one workspace; one workspace serves many teammates, each with a role.
Every page lives at the workspace's own address, productos.ca/<workspace>/features/<id>, so a link says which workspace it belongs to. A link without the workspace (an older one, or one typed by hand) opens in the workspace you came from, or the one you used last.
Belonging to several workspaces
Being rolled out: one account can belong to several workspaces, with a separate role (and function) in each. Switch from the bottom of the sidebar, with G then W, or from the command palette. Each browser tab stays in its own workspace, so two tabs can show two workspaces side by side.
- API tokens are issued in one workspace and only ever work there, whichever workspace you have open.
- Connected apps (claude.ai, Claude Code) work in one workspace too. When you belong to several, the consent screen asks which one; connect again to add another.
- Integrations connect in the workspace whose settings page you started from.
- An item opened in the wrong workspace (a link from another tab) offers to open it in its own.
Roles at a glance
The role hierarchy is a strict total order: viewer < commenter < member < admin < owner.
| Role | Reads | Writes | Manages members | Manages billing | AI features |
|---|---|---|---|---|---|
| Owner | All | All | Yes | Yes | Ask + generate |
| Admin | All | All | Yes | No | Ask + generate |
| Member | All (no audit log) | All entities; no permanent delete | No | No | Ask + generate |
| Commenter | All (incl. via API tokens / MCP); no audit log | Comments only | No | No | Ask only (questions, insights, search); no generation |
| Viewer | All workspace entities; no audit log | None | No | No | Ask only; no generation |
Roles are workspace-wide. There's no per-feature or per-product permission level, that would multiply the model without buying real isolation. If you need finer-grained sharing (e.g. a customer-facing roadmap), use the public surfaces (portal, roadmap, changelog) instead of bending RBAC. They are off by default and switched by an owner or admin, as described in the Settings overview.
The same matrix is enforced at the database, API and UI layers.
What each role typically does
- Owner: the person who created the workspace. Exactly one per workspace; transferable. Owns transfer, the bulk import, the workspace-wide security policy, and the danger zone.
- Admin: co-founders, lead PMs, eng leads. Same write powers as the owner, plus manages integrations, AI settings, members, API tokens, and the audit log. Can't transfer ownership, run the bulk import, require 2FA workspace-wide, or delete all data.
- Member: the day-to-day PM seat. Creates and edits Golden-Thread entities, runs AI features, manages tags and custom fields. Cannot invite members, manage integrations, issue API tokens, permanently delete, or read the audit log.
- Commenter: non-human callers (API tokens, MCP integrations, AI agents) plus the rare sales / support seat that should react without changing data. Reads everything but cannot mutate structured entities or trigger AI generation. The default role for newly issued API tokens.
- Viewer: read-only stakeholders (execs, customers under NDA, auditors). Excluded from the audit log and integration secrets.
Inviting members
Settings → Members & Roles → Invite member. Type an email, pick a role (admin, member, commenter or viewer), hit invite. ProductOS emails an invite link; if the email can't be sent you get the link to copy and share yourself. Invites expire after 14 days. Only the workspace owner goes through the onboarding wizard; invited members go straight to the dashboard.
How roles interact with API tokens
API tokens carry their own role, fixed at issuance (default commenter, capped at the issuer's own role, so an admin can't mint an owner-level token). Every API call runs at that role. The issuer's current role matters in one way: ProductOS revokes any token whose stored role is higher than the issuer's new role, so demoting someone immediately kills their over-privileged tokens, no manual revoke needed.
Tokens are issued and revoked from Settings → API Tokens (admin or owner). Tokens created by an MCP OAuth sign-in show up in the same list.
MFA
Set up per user under Settings → Account → Security. Owners and admins see each member's 2FA status in Settings → Members & Roles and can reset it. Owners can require 2FA for everyone from Settings → Workspace → Security; members without it are sent through enrollment on their next visit. Google sign-in is available on the login page; SAML / enterprise SSO is not.
Transferring ownership
From Settings → Members & Roles: change a member's role to Owner and confirm. The swap is atomic (you become admin, they become owner), so there's no half-transferred state; sign in again if your role looks stale afterwards.
Deleting workspace data
Owners only. Settings → Danger Zone → Delete all data permanently deletes every Golden Thread entity, accounts, personas, products, modules, team members, links, insights, embeddings, activity-log rows and integration connections once you type DELETE ALL DATA; strategy, intelligence, GTM, sales and design-system records, the workspace itself, your account, API keys, settings and naming customizations survive. There is no self-serve deletion of the workspace or the account yet: email support@productos.ca.
Next
- The Golden Thread: what all those entities actually are.
- API authentication: how tokens, scopes, and roles compose in practice.