# Members and roles

Workspace Settings lists existing members and their current role. Role changes affect access on the next request, even when the person's browser session is still open. Agents, drafts, versions, and conversations remain workspace data when membership is removed.

## Understand the three roles

An **owner** can grant owner, admin, or member; change another member's role; remove permitted members; and use all workspace administration screens. An **admin** can operate administrative product features but can grant only member and cannot change or remove another admin or owner. A **member** can use ordinary workspace features and read Conversations, but cannot manage administrative settings.

No person can change their own role. This prevents self-promotion and makes role transfer an explicit action by another owner. A workspace must always keep at least one owner, so the last owner cannot be demoted or removed.

For the broader permission boundaries, see [Permissions and security](/docs/workspace/permissions-and-security).

## Change or remove existing members

Open **Settings → Members**. The table contains the name, email, and role for existing members. If your role permits a change, select the new role in that person's row. A rejected server update leaves the displayed role unchanged.

Use **Remove** to revoke another person's membership. An admin can remove a member; only an owner can remove an admin or owner. Access disappears on the removed person's next request, while their agents and conversations stay in the workspace. Their private per-user drafts are retained rather than being deleted as a side effect.

Use **Leave** on your own row to leave the workspace. Leaving yourself is allowed for any role, except when you are the last owner. After a successful leave, the dashboard returns to the workspace picker because the old workspace is no longer accessible.

## Invitation availability and recovery

Invite or add member is not available in the UI or API. The public member endpoint lists existing membership, changes an existing role, or removes an existing member; it does not turn an email or an unrelated user ID into membership. Attempting the unsupported add route is rejected.

Before an owner leaves, another existing member must already be promoted to owner by a different owner. If a member was removed accidentally, there is currently no customer invitation flow to add them back; coordinate through the authorized internal membership process rather than trying a role PATCH for a non-member.

For API automation boundaries, see [workspace API keys](/docs/workspace/api-keys). Never share a dashboard session or API key as a replacement for missing membership.