> ## Documentation index
> The full klickops handbook index is at https://klickops.io/llms.txt
> The HTML of this page is at https://klickops.io/en/docs/members
> Language: en

# Members and roles

Who is in your organization and what each of them may do.

## What it is

Everyone who can see anything in klickops is a member of an organization with exactly one role. That role decides what they can do across every project in it.

There are three, and they are deliberately few. Most access questions are answered by "can this person change things", and inventing a fourth role usually means the projects want splitting instead.

| Role | Can | Cannot |
| --- | --- | --- |
| Viewer | See everything: workloads, logs, metrics, configuration key names | Change anything |
| Editor | Everything a viewer can, plus deploy, edit, restart, restore, delete workloads | Manage members, billing, or organization settings |
| Admin | Everything | nothing |

## When you'd use it

- Somebody joins and needs access.
- A contractor should see logs but not touch production.
- Somebody leaves, and their access has to go with them.

## Invite somebody

1. Go to **Members** in the organization and invite by email address.
2. Pick the role. Choose the smallest one that lets them do their job; raising it later is one click.
3. They accept and land in the organization.

An invitation is not access. Until it is accepted, nothing has been granted, and you can revoke it in the meantime.

![The Members page of an organization, with each person's role.](/handbook/members.webp)

## Narrowing access to one project

A role applies to the whole organization. When somebody should only reach one project, give them a per-project role instead, which overrides the organization one for that project alone.

Use it sparingly. Per-project overrides are how an access model becomes something nobody can reason about; two organizations are often the clearer answer.

## Settings reference

| Setting | Default | What it does |
| --- | --- | --- |
| Role | viewer | The organization-wide permission level. |
| Per-project role | none | Overrides the organization role for one project. |
| Invitation | pending | Grants nothing until accepted. Revocable at any time. |

## Limits and gotchas

- **Removing somebody is immediate.** Their sessions stop working, and anything they were running keeps running.
- **An editor can delete a project.** That is the same power as deploying one, and it deletes what is inside. If that is too much, they are a viewer with per-project editor rights where they need it.
- **Roles do not stack.** The most permissive grant wins rather than combining.
- **Billing is admin-only.** An editor cannot see what the organization spends.

> [!Careful]
> The last admin cannot be removed, since an organization with no admin cannot be administered. Promote somebody first.

## Related

- [Organizations, projects, workloads](/docs/concepts) for what an organization contains.
- [Plans and costs](/docs/billing) is admin-only and lives at the same level.