Team & invites.

SpecGraph workspaces are multi-tenant. One person can run a workspace solo for years; many teams share a single workspace for a single product. This page covers everything that happens between those two extremes.

This page is about workspace membership — long-lived accounts on the team page. For per-project, time-limited reviewers (regulators, customers, vendors), see Stakeholders instead — they're a different model with different controls.

Roles #

Five roles, ordered from most to least permission:

The Owner role is special: an owner cannot be removed and cannot be demoted by anyone except themselves (or by another owner promoting first, then demoting). This is the safety hatch — there's always someone with the keys.

The Stakeholder workspace role is for people who only attend interviews and submit wishes, with no spec-edit power. It's distinct from the per-project stakeholder portal; the workspace role gives an account, the portal is link-only.

Inviting workspace members #

From Team in the top nav, click + Invite members. You can paste many addresses at once (comma, semicolon, newline, or spaces all work) and pick a single role for the batch.

Two things can happen per email:

• Already a SpecGraph user? They're added immediately. The success summary calls these out as "Added N existing users".
• New email? A magic-link invitation is queued through Resend. They get the email, sign up, and the membership is granted automatically on first sign-in. Summary calls these out as "Sent N invitation emails".

Mixed batches return both counts in one toast. Failures (rate limits, bad addresses) come back as a per-row reason in the same toast.

Pending invitations show in a Pending invites section under the member list, with resend and cancel controls. Each invite expires after 14 days. Resend rotates the token; cancel kills it on the spot.

The address book #

Workspaces accumulate the same external reviewers across projects — a partner PM, a security auditor, a regulator. The Address book tab on the Team page is a per-workspace list of these contacts, with name, email, organization, title, and department.

Once a contact is in the address book, the per-project Share panel's "Pick from address book" combo fills the invite form in one click. Favourites (★) sort first.

Address book contacts are not accounts — adding someone here doesn't give them access. It's a typing shortcut. To grant access, invite them as a stakeholder on a specific project.

See Address book for the full management page.

Departments #

Each member has a department tag (product, engineering, qa, etc.). Departments are per-workspace — owners and admins manage the list under Settings · Departments, and the colour-coded labels are reused everywhere a person or wish gets categorized. The default set covers the seven phase-owning functions plus a system row, but you can rename, recolour, or extend the list to match your org.

The pencil icon next to a member's department on the Team page opens a picker; the role pencil works the same way.

Per-project access #

Workspace role is the ceiling on what someone can do. Project access is the gate that decides which projects they see at all.

• Owners and admins see every project in the workspace, always.
• Editors, viewers, and stakeholders only see projects they're explicitly added to. By default they see nothing.

Owners and admins manage access from the project's Settings · Access section — see Project access for the full flow. Adds are restricted to existing workspace members; you can't grant project access to an external email without inviting them to the workspace first.

For the complete role × permission matrix (what each role can do once they're in), see Roles & permissions.

Removing someone #

From Team, click the remove action on the row. Their account is preserved; only the membership is dropped. They can be re-invited later and any project authorship history is retained. Owners cannot be removed — demote first.

If the person owns projects, ownership transfers to the workspace admin who removed them. Re-assign as needed before letting them leave critical engagements.

A note on the audit log #

Every team-membership change writes to the per-workspace audit log, including:

• Who invited / accepted / removed
• The role granted at each point
• Which projects the person had access to at the moment of removal

For regulated verticals this isn't optional — it's how you reconstruct who could see what during a given window.