docs: workspace admin roles (workspace-admin-roles) [auto-draft]

[rachaelrenk]

Summary

Auto-drafted documentation for Workspace admin roles (spec workspace-admin-roles).

This page introduces the workspace-level role model (User / Admin / Owner), describing what a workspace admin can and cannot do across membership, billing, settings, Oz agent run visibility, and team-level management. It was generated in ambient mode by the scan-new-specs → write-feature-docs workflow from the merged PRODUCT.md only. No content was derived from TECH.md, and no internal DB schema or permission function names are exposed.

• Spec: warpdotdev/warp-server → specs/workspace-admin-roles/PRODUCT.md
• Spec PR: https://github.com/warpdotdev/warp-server/pull/13329
• New page: src/content/docs/enterprise/team-management/workspace-admin-roles.mdx
• Sidebar: placeholder entry added under Enterprise → Team management in src/sidebar.ts (marked // [TODO: docs reviewer — confirm placement])

Docs outline (auto-generated)

The following outline was generated from the spec. @IsaiahWitzke: please review and check off each item, or leave a comment with corrections.

Content structure

• H1 / title: Workspace admin roles
• Opening paragraph: workspaces are the top-level org unit containing multiple teams; workspace admin roles delegate whole-workspace management with capabilities that are a superset of team admin.
• Workspace roles section: User, Admin, Owner definitions and the "admin-level" term.
• How it works section: additive on top of team roles, admin-level permissions across every team, team admin ≠ workspace admin, owner as root of trust, and the two management paths (self-serve vs multi-team-capable plans).
• Workspace admin capabilities: member management, billing, Oz agent run visibility, team-level management.
• Owner-only capabilities: ownership transfer.
• Role changes and constraints: owner can't self-demote, admin can't self-remove, demotion is immediate.
• Related pages: roles-and-permissions, teams, admin-panel, viewing-cloud-agent-runs.

Items needing engineer verification ⚠️

• Release availability of follow-up capabilities. The spec lists workspace invite links, email invites, domain restrictions (invariants 10–13), and workspace-level spend limits as V1 non-goals shipping as follow-up. The draft documents them but flags them. Confirm what is actually available now vs. later.
• Workspace management UI / settings path. UI/frontend design is an explicit non-goal in the spec, so no Settings path or step-by-step procedure is documented. The "Managing workspace roles" section is a [TODO] placeholder — confirm the surface and path once shipped.
• "Only visible to me" run-visibility wording. Confirm the exact user-facing label for personal (non-team) Oz runs.
• Plan tiers. Confirm which plans count as "self-serve" vs "multi-team-capable" so we can name them concretely instead of describing the capability abstractly.
• Screenshot — workspace member management surface showing roles (computer use unavailable in this run; left as a placeholder).

Verified from codebase ✅

• Workspace role model (USER / ADMIN / OWNER) and workspace-level admin permissions confirmed in warpdotdev/warp-server (logic/permissions/permissions.go, logic/workspace_teams.go).
• Placement alongside the existing team-management pages (roles-and-permissions.mdx, teams.mdx, admin-panel.mdx) confirmed via src/sidebar.ts.

Outstanding [UNVERIFIED] / [TODO] items in the draft

• [TODO: engineer to verify which capabilities are available in the current release.] (caution callout)
• [TODO: engineer to verify — invite links, email invites, and domain restrictions ... confirm availability.]
• [TODO: engineer to verify availability.] (invite link management)
• [TODO: engineer to verify availability.] (domain restrictions)
• [TODO: engineer to verify — workspace-level spend limits are follow-up work ...]
• [TODO: docs reviewer — add the step-by-step procedure and settings path ...] + UNVERIFIED: exact Settings menu path
• [TODO: docs reviewer — screenshot needed: workspace member management surface showing roles.]

Reviewers

/cc @IsaiahWitzke
Requesting review from @rachaelrenk and @hongyi-chen.

Conversation: https://app.warp.dev/conversation/7abbf494-93ec-4cf3-b692-738012aea1f5
Run: https://oz.warp.dev/runs/019fae9f-b508-7cf4-aa29-090a32193523

This PR was generated with Oz.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Jul 29, 2026 4:11pm