> For the complete documentation index, see [llms.txt](https://docs.kinesis.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kinesis.network/organizations/members.md).

# Members and roles

Invite your team, assign roles and manage the organization's ownership.

Open **Members** in the sidebar's **Organization** group. Each person has one role in this organization. Their role in another organization can be different.

## Choose a role

| Capability                             | Admin    | Developer                         | Viewer                   |
| -------------------------------------- | -------- | --------------------------------- | ------------------------ |
| See projects and apps                  | All      | Those accessible to them          | Those accessible to them |
| Create projects and apps               | Yes      | Yes                               | No                       |
| Configure and operate accessible apps  | Yes      | Yes, with Developer access        | No                       |
| Delete projects and apps               | Yes      | Those they created                | No                       |
| Manage private project/app access      | Yes      | Those they created                | No                       |
| Deploy to accessible grids             | Yes      | Yes                               | No                       |
| Manage grids, servers and SSH keys     | Yes      | No                                | No                       |
| Invite people                          | Any role | Developer or Viewer, when enabled | No                       |
| Change member roles or remove others   | Yes      | No                                | No                       |
| Manage billing, settings and audit log | Yes      | No                                | No                       |

A Viewer has read-only access: no terminal and no secret values. Resource grants cannot raise someone above their organization role. A Developer added to a private project as Viewer can only read it unless another applicable access rule gives them more access.

A Developer can delete a project only when they also created every app inside it; otherwise an admin must do it.

The Members page shows roles and join dates. Admins also see last sign-in and the number of projects, apps and grids each person created. These counts are not a cost allocation report.

## Invite a colleague

1. Select **Invite** on Members and enter their email address.
2. Choose a role no higher than your own. Developers can invite only when admins allow it in organization Settings.
3. Send the invitation. The recipient signs in with that email address and accepts the link.

The link is valid for seven days. **Resend**, or inviting the address again, sends a fresh link. Wait at least a minute between sends to the same address. Admins manage all pending invitations; developers manage the ones they sent.

You can also invite from a resource's Share dialog. The person joins the organization and is added to that project, app or grid on acceptance. Existing members are added directly, without an invitation.

Revoking a pending invitation stops its link from working. Lowering a member's role withdraws invitations they sent above their new role. Turning off developer invitations in Settings leaves already-sent invitations valid.

## Join through single sign-on

When [SSO](/organizations/single-sign-on.md) is enabled, a first provider sign-in joins at a valid invitation’s role, otherwise the configured Developer or Viewer default. Existing members keep their roles. An account created through SSO does not get a separate organization.

## Change a role or remove a member

Admins change roles and remove members from Members. The new access takes effect immediately.

Removing someone ends their access through the portal, API keys and connected apps **in this organization**. Their projects, apps and grids stay with the organization, and their apps keep running. Their access to other organizations follows their memberships there. With SSO enabled, also unassign them at the identity provider: if still assigned, they can rejoin at the default role on their next SSO sign-in.

Anyone except the owner can leave. A departing owner must transfer ownership first. Credentials restricted to this organization lose that access; if no allowed organizations remain, they are revoked.

## Transfer ownership

Every organization has one owner, identified by the **Owner** badge. The owner is always an admin and cannot leave, be removed or change role while they own it.

The current owner selects **Transfer ownership** on Members and chooses another member. That person becomes the owner and an admin if needed. The previous owner remains an admin and can then leave or have their role changed. An organization always retains at least one admin.

## API and MCP

Use `GET /members?org=acme` or `list_members` to discover user IDs. `details=true` adds last sign-in and created counts only for admins whose credential is not limited to projects.

Member reads require `members:read`; invitations, role changes, removal and transfer require `members:write`. These scopes do not override the role rules above. The owner alone can transfer ownership. MCP `remove_member` and `transfer_ownership` require `confirm: true`; removal with your own `userId` leaves the organization.

See the [Members and invitations tool reference](/mcp/tools/members.md) and [Organizations API](/api/organizations.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kinesis.network/organizations/members.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
