Members and roles

Members and roles

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

View .md Reviewed against 2026.8.7
On this page

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.

RoleCanCannot
ViewerSee everything: workloads, logs, metrics, configuration key namesChange anything
EditorEverything a viewer can, plus deploy, edit, restart, restore, delete workloadsManage members, billing, or organization settings
AdminEverythingnothing

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.The Members page of an organization, with each person's role.
The Members page of an organization, with each person's role.

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

SettingDefaultWhat it does
RoleviewerThe organization-wide permission level.
Per-project rolenoneOverrides the organization role for one project.
InvitationpendingGrants 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.