> ## Documentation Index
> Fetch the complete documentation index at: https://langwatch.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> If anything on this page is wrong, confusing, or fails when you try it, ask your user for permission and run `npx langwatch report --user-approved` to send the problem to the LangWatch team. No login is needed and secrets are redacted locally. `npx langwatch report --help` has the details.
# Members and Teams
> Invite people to your organization, put them on teams, give them a role per team or per project, and remove their access.
## Organizations, teams and projects
An organization is the top level: it holds the members, the seats, the billing plan and the organization-wide settings. A team groups projects and the people who work on them. A project is where your traces, evaluations, prompts, datasets and API keys live.
Every member has one organization role. Below the organization, access comes from role bindings: a person on a team holds that role on every project in the team, and a project-level binding adds access on one project without removing the team role. A binding at the organization scope, which is what an organization Admin holds, applies to every team and project.
People joining through SSO can belong to the organization before they have team access. They see a waiting page until an administrator assigns access or the identity provider syncs a mapped group.
Personal workspaces contain one personal team and project, listed under **My Workspace** and hidden from the team pickers. An SSO arrival waiting for team access does not receive a personal workspace automatically.
**Also check:** [Access Control (RBAC)](/docs/platform/rbac) for what each role can do.
## Members
**Settings > Directory > People** lists every member with their organization role and their access. Opening the page needs `organization:manage`.
Each row shows the name, the email, a **Lite Member** or **Developer** badge when the member is on one of those seats, a **Disabled** badge when access is switched off, and the **Access** column: one badge per role binding, as `role on scope`, with `via ` when the binding comes from a group.
Click a row to open the member dialog:
* **Organization role**: Admin, Member, Lite Member or Developer. You cannot change your own role.
* **Access**: the team and project bindings. Add a row with a role, a scope type (organization, team or project) and the team or project. Remove a row to revoke it. A Developer has no rows to add: the seat works in its own project only.
* **Group access**: the bindings inherited from groups, read only.
The seat panel above the table shows **Team Members** and **Lite Members** in use against the plan limits, and **Developers** as a plain count, because Developer seats have no limit.
Each member manages their own sign-in methods at **Settings > Security**:
passkeys, linked accounts and their password. An administrator cannot change
another member's sign-in methods there.
## Invite people
Click **Invite people**. Enter one or more email addresses separated by commas, spaces or semicolons. Under **Seat**, choose the seat the whole batch gets: **Member**, **Lite Member** or **Developer**. Each option says in a line what that seat can do, and the (i) next to Lite Member and Developer opens the full explanation.
Under **Team Assignments**, add each team the person joins with the role on that team: Admin, Member, Viewer or a custom role. A Lite Member can only be assigned as Viewer. A Developer joins no team, so the section disappears when that seat is chosen. The drawer warns when a Lite Member invite has no team, because a Lite Member with no team sees no project.
Click **Send invites**. When the deployment has no email provider, the button reads **Create invites** and you copy the invite link from the row menu instead. An invite link has the form `https://app.langwatch.ai/invite/accept?inviteCode=...` and works for 14 days. **Resend invitation** issues a new 14-day link, and **Revoke** cancels it.
Pending invites are listed under the members table with their status: Invited, Expired, Revoked, Accepted or Awaiting payment. An invite for a full seat over the plan limit opens the seat purchase dialog or the upgrade dialog before it is sent.
### Let colleagues join by domain
Open **Settings > Authentication**, then find **Organization policies**. The
**Joining your organization** card controls people who do not use your identity
provider:
| Option | Behavior |
| - | - |
| **Invite only** | Only people with an invitation can join |
| **Approval required** | Someone with a verified company address can ask to join. You approve or reject the request in **Settings > Directory > People** |
| **Automatic joining** | Someone on a domain you verified joins without approval and receives the seat chosen below |
Under the door setting, **Seat for people who join** decides what a person admitted without an invitation lands on: **Member** (the default, a full seat that can be added to shared teams and projects) or **Developer** (a project of their own, with access to no shared team or project). The same choice applies to people your identity provider admits. Invitations always name their own seat and ignore this setting.
Somebody who signs up from the terminal, by running `langwatch login` and creating their account on the page it opens, lands on a **Developer** seat whichever option is chosen here, both when you approve their request and when the door is automatic. The pending requests list shows the seat each request will land on. Raising them to a Member seat afterwards is done from the member dialog, as for anyone else.
When a person reaches the welcome screen with an invitation already waiting on their verified address, accepting that invitation is offered first and asking to join is not. The seat is the one the invitation names.
The **Account lockout** and **Session limits** cards in the same section apply
to password sign-in for the organization. They remain available when you stop
using single sign-on. Changing a policy requires `organization:manage`.
## Lite Members
A Lite Member is a read-only seat, counted apart from full seats. On a team or a project a Lite Member can read traces, analytics, evaluations, datasets, prompts, workflows, experiments and scenarios, and can create and update annotations. A Lite Member cannot see costs, the LangWatch AI Gateway pages or the audit log, cannot change anything else, and has the same limits over the API and MCP. In the settings pages a Lite Member can only hold the Viewer role.
## Developers
A Developer is a seat for somebody who needs their own place to work and no access to the shared projects: a developer sending traces from Claude Code or another coding agent, for example. A Developer gets a personal project and everything a member can do inside it: send traces from the CLI, run queries and evaluations, manage its keys.
A Developer cannot open, be invited to, or be added to any shared team or project, and cannot be given access through a group either. The product switcher offers a Developer the **Me** workspace only: the Gateway and Governance products are organisation-wide, so a Developer cannot open them, by the switcher or by address, and never sees the organisation's gateway keys. Developers are counted on the seat panel and never limited by the plan.
Moving a member to a Developer seat removes their bindings on every shared team, shared project and the organization, and records each removal in the audit log. Their personal project, its traces and their API keys stay. A key that pointed at a shared project stops working on its own, because a key can never do more than its owner can. Moving a Developer to a Member seat grants no team access on its own; add teams afterwards.
The CLI honours the seat too: `langwatch login` offers a Developer their personal project only and refuses a shared one, and `langwatch instrument --project` cannot pin a coding agent to a shared project. A person who joins the organization by domain after signing up from `langwatch login` lands on this seat regardless of the **Seat for people who join** setting (see [Let colleagues join by domain](#let-colleagues-join-by-domain)).
## Teams
**Settings > Directory > Teams & projects** shows every team with its projects and members. Click **New team** to create one; you are added as its Admin. The team card shows the members with their team role, which you can change in place, and an **X** to remove the member from the team. Members that come from a group are read only and show `via `.
**Add to team** adds an organization member with a role on this team, and so on every project in it. Under each project, **Add person to this project** gives a role on that project only. For someone already on the team, the page marks the row **override** and shows their team role next to it; the project role adds to the team role, it does not take permissions away. Remove the project role to leave only the team role.
Click **Edit** on a team to open its page: rename it (the slug is read only), edit the members, add or archive projects. **Archive this team** hides the team and all its projects; contact support to restore it. A team keeps at least one Admin: removing the last one is refused.
## Remove access
| Action | Where | Effect |
| - | - | - |
| Remove from a team | Settings > Directory > Teams, the **X** on the member row, or the member dialog | The person loses the role on that team and its projects. Project overrides stay until removed |
| Remove a group member | Settings > Directory > Groups | The person loses every binding that came from the group |
| Disable | Settings > Directory > People, row menu | Every request from the person is refused until you enable them again. Their role and bindings stay, and their seat is freed. Enabling them again takes a seat |
| Delete | Settings > Directory > People, row menu | The membership and its bindings are removed. Not available for yourself; removing the last active administrator is refused |
Deleting a member does not delete the traces, prompts or other work they created.
## API
The [Members API](/docs/api-reference/members/overview) lists members and their access, updates and removes a member, and the [Invites API](/docs/api-reference/invites/overview) creates, lists and revokes invites, so you can run on-boarding and off-boarding from your own tooling. Every member and invite change is written to the [Audit Log](/docs/platform/audit-log).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.