Invite teammates into a workspace with owner, editor, and viewer roles. Invitations require acceptance, and the UI stays honest about what each role can do.
Roles
Every workspace member has exactly one role, checked centrally on every request — never just hidden in the UI:
Role
What they can do
Owner
Full control — rename/delete the workspace, deploy to prod, manage members, export/import, view audit logs. There's exactly one owner, the workspace creator.
Editor
Save versions, run prompts and chains, manage evals and test cases, deploy to dev/staging, and export. Cannot delete the workspace, deploy to prod, or manage members.
Viewer
Read-only access to every prompt, chain, and version in the workspace.
Inviting someone
From Settings → Workspace → Members (owner only), invite a teammate by the email address of their existing PromptVersions account.
1
Send the invite
Enter their email and pick a role (editor or viewer). This creates a pending membership — it grants no access yet.
2
They get notified
The invitee sees the invite in their notifications bell with inline Accept / Decline actions.
3
Accept to join
Accepting flips the membership to active and the workspace immediately appears in their switcher. Declining removes it.
Pending means no access
A pending invite is invisible to workspace data — it behaves exactly like a non-member (404, not 403) until the invitee explicitly accepts. Re-inviting an already-pending or already-active email is rejected rather than silently duplicated.
Seats are capped by plan
Team member seats depend on the workspace owner's plan: Free workspaces are solo (no invites), Pro allows up to 3 members, and Team allows up to 25. Inviting past the cap returns an upgrade prompt rather than a silent failure.
Changing roles & removing members
Owners can change a member's role or remove them at any time from the same Members panel. Both actions notify the affected member and take effect on their next request — a removed viewer's tabs simply stop loading data.
Role-gated UI
The frontend mirrors the server-side checks with useWorkspaceRole(): viewers see a "View only" experience — Save, New, Delete, Deploy, Run, and tag controls are hidden rather than failing after a click. Editors see everything except prod deploy/undeploy and member management, which stay owner-only.
Runs need editor access
Running a prompt or chain — in the UI, via compare, or through the optimizer — writes a run log, so it requires at least editor. Viewers can read every version but can't execute one.