> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noisemaker.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Team

> Manage workspace members, invites, and role safeguards.

Team access is stored per workspace. Only active members can open workspace data.

## Roles

| Role   | Typical authority                                                      |
| ------ | ---------------------------------------------------------------------- |
| Owner  | Full workspace control, including owner membership changes             |
| Admin  | Manage members and most workspace operations, but not owner membership |
| Member | Use workspace features allowed by the route and action                 |

The general access layer also understands a Viewer role for authorization compatibility. Durable team invites and role changes currently use Owner, Admin, and Member. The Team UI invites Admin or Member.

## Invite flow

<Steps>
  <Step title="Enter the member">
    Supply an email, display name, and Admin or Member role.
  </Step>

  <Step title="Create the invited record">
    The status is <code>invited</code> and <code>joinedAt</code> remains empty.
  </Step>

  <Step title="Activate membership">
    The identity must be matched and the membership made active before it grants workspace access.
  </Step>
</Steps>

Email uniqueness is case-insensitive within the workspace.

<Warning>
  Invite delivery is currently a mocked or logged integration. Creating an invited record does not prove that an external email was delivered.
</Warning>

## Management rules

* Owners and admins can manage team records.
* Only an owner can add, change, or remove another owner.
* The last active owner cannot be demoted or removed.
* An invited member does not gain access until active.
* Cross-workspace member identifiers are returned as not found.

The current UI does not offer role changes or removal for an Owner. The service preserves the stricter owner-only path for supported administrative calls.

## Removing access

Removal takes effect at the membership layer. Existing workspace API keys are separate machine credentials and are not revoked automatically when a person is removed. Review API keys after an ownership or operator change.