Team Members
Understand Team membership, Team roles, Issue work access, hierarchy constraints, and policy-controlled member management
Team membership controls who belongs to a workspace Team. It determines normal Team Issue work access and can participate in policy-controlled Team management.
Adding someone to a Team does not give them Module, artefact, baseline, review, Spec-Driven Development, or restricted source access beyond what they already have.
Team roles
| Role | What it can do |
|---|---|
| Team owner | Manage the Team by default and use owner-only Team controls. |
| Team member | Do normal Issue work in Teams they can access. |
Normal Team Issue work includes creating Issues and editing title, description, status, priority, assignee, labels, primary Feature, and icon color.
Default Team membership
The default Team mirrors workspace membership automatically:
- New workspace members are added to the default Team.
- Removed workspace members are removed from all Teams in that workspace.
- Re-invited members can be added again through normal membership flows.
This keeps Team member lists current with the workspace roster.
Add members to a Team Owner Admin
Open Teams settings
Open Workspace Settings -> Teams.
Select an active Team
Choose the Team whose members you want to manage.
Add a workspace member
Use the member selector to add a person who is already a workspace member.
Only workspace members can be added to Teams. Team member management is controlled by the Team's Member management policy: owners only by default, or all Team members when that policy allows it. Owner safeguards still apply.
For child Teams, the person must also be an active member of every active parent Team. Integrity filters add-member candidates through the same server rule that validates the final membership write.
Remove members from a Team Owner Admin
- Open Workspace Settings -> Teams.
- Select an active Team.
- Find the member.
- Use the remove action.
The Team detail Members tab also shows member-management row actions for authorized users on active Teams. Unauthorized users and archived Teams show read-only member rows.
If removing someone from a parent Team would leave them in active child Teams, Integrity asks for explicit confirmation and removes the affected child-Team memberships first. The strict backend path still blocks invalid parent removal unless that cleanup path is used.
Archived Teams
Archived Teams keep their history and stable route, but member management is disabled while archived. Restore the Team before adding or removing members.
Join, request access, and leave Admin Editor Viewer
- Eligible workspace members can join a public Team from its settings hub.
- A private Team can expose Request access only through an explicitly allowed discoverable entry; hidden private Teams remain hidden.
- Members can leave non-default Teams when owner and hierarchy safeguards allow it.
- The default Team cannot be left directly because it mirrors workspace membership.
Requests and invitations are current-state queues. Approved, denied, declined, revoked, or replaced rows leave the operational list and remain in audit history.
The same membership workflows are available to an authorized coding agent. Direct member additions, eligible joins, invitations, responses, requests, and routine role changes use current server permissions. Removing a member with child-Team cleanup, reducing owner access, or adding people across descendants requires an exact preview and confirmation. A hidden private Team is never revealed merely because an agent attempts one of these actions.
Team owners
An active private Team must always have at least one owner. Authorized managers can promote and demote Team members, but Integrity blocks removing or demoting the last owner. Team ownership is local to the Team and does not change the person's workspace role.
Audit evidence
Team member add/remove and Team permission policy changes write audit rows with:
- Team id
- Team name snapshot
- Team slug snapshot
- Affected user
- Actor
Private Team hierarchy events use display-safe labels. Unauthorized viewers do not receive hidden private Team names, slugs, icons, or member lists from logs.
Workspace admins can review those events in Workspace Settings -> Audit log.
Access and permissions
Use Team settings -> Access and permissions to choose whether Team settings, Team Issue labels, and Team member management are limited to Team owners or delegated to all Team members.
Coding-agent action discovery uses these same policies. A visible Team, a workspace role label, or an old cached action does not grant authority; the server rechecks the current actor, Team access, policy, lifecycle state, and target version when the action applies.