Organization, workspaces and people
How an organization, its workspaces and your personal workspace fit together, inviting people, who reaches what, what counts as a seat, agents and tokens, and your own account.
The shape
| Level | What it holds | Where you manage it |
|---|---|---|
| Organization | The company: its people and seats, the plan and AI credits, the organization's AI provider, single sign-on and the audit log. Outbound email is one mailer for the whole deployment, changed only by its platform admins and, when the operator names one, the admins of the organization that runs the install — the deployment mailer. | Settings → Organization — People, Plan & billing, AI, SSO, Email, Audit log. |
| Workspace | One product's work — boards, projects, tasks, sessions, files — kept apart from every other workspace, under its own encryption key. | Settings → Workspace — its identity, projects, trackers, members, GitHub, AI, agents and tokens. |
| Personal workspace | Yours alone: made the first time you use your diary, invisible to everyone else, never shareable. Your diary lives there — your day. | The workspace chip, where Personal then stays. |
Creating a workspace
+ new workspace under your workspaces on All workspaces takes a name and, when you administer more than one organization, which of them it belongs to. Only an organization's admins and owners create workspaces in it; anyone else's new workspace starts an organization of their own. Settings → Workspace → Workspace then gives it the identity every member sees: its name, mark, accent colour and a note about it. Projects can later be merged or moved to another workspace — projects.
Inviting people
Organization admins and owners invite from Settings → Organization → People: an email and an organization role — member, admin or owner, never above your own. A member invite also names the workspace they join and their role there (member, viewer or admin). Owners and admins reach every workspace, so their invite names none.
- Nobody is seated until they join. The invitation waits in the invitee's account menu, under waiting on you on their home and, when the deployment can send mail, in their inbox. They join or decline with one click; someone creating their account from the invitation link joins on the spot.
- The link is single-use, bound to the invited address and valid for 7 days; sending it again replaces it.
- Single sign-on — a person who signs in through the organization's SSO for the first time joins the default workspaces set on that connection — single sign-on.
Who reaches what
- Organization owners and admins reach every workspace of the organization as admins.
- A member reaches only the workspaces they were granted. The People page lists each person's workspaces with the role in each, and a grant is added or removed right there; Settings → Workspace → Members shows who can open that one workspace.
- Inside a workspace the roles run viewer < member < admin < owner: a viewer reads, a member works — annotates, composes, files tasks, mints share links — and an admin also changes the workspace's settings. The full rules: roles.
- Removing someone from a workspace takes only that grant; their seat and other workspaces stay. Removing them from the organization ends the seat and every grant in it.
Seats
A seat is a member of the organization. Plan & billing and the People page show the count against the plan's limit, next to pending invites; the limit is checked when an invite is sent and again when it is accepted. Enterprise has no seat limit — the count reads unlimited — and neither does any organization on a self-hosted deployment that meters no plan, where every organization runs on Enterprise limits (billing settings). Never a seat: guests on a share link, agent identities and tokens.
Agents and tokens
- Agents — Settings → Workspace → Agents gives an AI actor its own revocable identity in the workspace. Its work is attributed to it by name, and it never counts as a seat.
- Tokens — Settings → Workspace → Tokens mints a credential for CI, scripts or an MCP client: a service or personal token with a role, or a report key for the bug-report widget or a recorder key, each tied to one project. Each is shown once. Connect an agent on the same page builds the one command that registers an MCP client with this workspace.
- The CLI and recorders sign in with a browser approval, never a pasted secret:
vitrinka auth loginin a terminal, or a code you approve under Link a device in the account menu. - Connected apps — an AI assistant that connects over OAuth asks for your consent once. One connection covers every workspace of that organization you belong to, landing in the home workspace you picked when a call names none; a viewer cannot connect one. You are notified when a new app is connected. Workspace admins see the apps members approved under Tokens → Connected apps, and revoking one cuts its access at once — agents and connected apps.
Your account
Settings → Security lists everything that can act as you — signed-in devices, connected apps, access tokens and passkeys — and each can be revoked on its own: sign out other sessions, disconnect an app, revoke a token, remove a passkey. Sign out everywhere revokes every session, this one included, every connected app and every access token at once; passkeys are removed one by one. A new sign-in or a newly connected app notifies you. Adding a passkey: passkeys.