# Members, roles, and permissions

Assign owner, admin, member, and viewer access at the organisation boundary.

Organisation roles apply across every project in that organisation. Assign the least privilege that
supports a person's work and review access when responsibilities change.

Roles govern human console actions. Runtime, client, and management keys use separate scopes and do
not inherit the permissions of a signed-in user after creation.

## Permission matrix

| Capability                                       | Owner | Admin | Member | Viewer |
| ------------------------------------------------ | :---: | :---: | :----: | :----: |
| Read projects, flags, environments, and activity |  Yes  |  Yes  |  Yes   |  Yes   |
| Change flags, targeting, and environments        |  Yes  |  Yes  |  Yes   |   No   |
| Create or revoke runtime and client keys         |  Yes  |  Yes  |  Yes   |   No   |
| Manage organisation identity and defaults        |  Yes  |  Yes  |   No   |   No   |
| Manage invitations, roles, and non-owner removal |  Yes  |  Yes  |   No   |   No   |
| Manage billing                                   |  Yes  |  Yes  |   No   |   No   |
| Create management automation keys                |  Yes  |  Yes  |   No   |   No   |
| Edit project identity and archive or restore     |  Yes  |  Yes  |   No   |   No   |
| Transfer or permanently delete a project         |  Yes  |  No   |   No   |   No   |
| Transfer organisation ownership                  |  Yes  |  No   |   No   |   No   |
| Begin organisation closure                       |  Yes  |  No   |   No   |   No   |

The matrix describes current customer authority. Internal platform administration remains isolated
behind FeatureGate operator controls and is never granted by organisation role.

## Choose a role

Use **Viewer** for people who need non-secret visibility into projects, configuration, and activity.
Viewers cannot reveal one-time secrets or mutate project state.

Use **Member** for engineers and operators who build inside projects. Members can change flags,
targeting, environments, and evaluation keys.

Use **Admin** for people responsible for organisation identity, membership, billing, automation keys,
and project settings. Admin is broader than project building and should remain limited.

Use **Owner** for the single person responsible for ownership transfer, project transfer and deletion,
and organisation closure. Do not use owner as a general seniority label.

## Protected ownership

Every organisation has one owner. Owners cannot be changed through ordinary role editing or removed
like another member.

A team owner can transfer ownership only to an accepted member. The recipient becomes owner and the
outgoing owner becomes admin in the same transaction, so ownership never disappears.

Personal organisation ownership is fixed. Promote the organisation or create a team organisation
when shared administrative ownership is required.

## Project and organisation authority

Members build project resources but cannot change project identity or lifecycle. Owners and admins
can archive projects and edit project settings.

Project transfer and permanent deletion are owner-only. A source owner can transfer only to an
organisation where they are owner or admin.

Organisation settings, membership, billing, and management keys belong to the organisation boundary.
Project membership roles do not exist separately in the current model.

## Credentials are separate

Creating a runtime key grants that key its selected scopes until revocation, even if the human creator
later changes role. Review and rotate credentials as part of access changes.

Management keys are non-human automation identities. Owners and admins can create them, but possession
of a management key does not sign someone into the console.

Organisation roles never authorize runtime API calls directly. The public API requires the correct
Bearer credential family and scope.

## Review access

Review membership when a person changes team, leaves the company, gains billing responsibility, or
becomes an automation owner.

For each change:

1. Update the human role or remove membership.
2. Review keys created or operated by that person.
3. Transfer ownership before removing an owner.
4. Confirm activity records the change.
5. Verify mandatory access-change email reached the affected person.

## Common problems

- **An owner cannot be removed:** transfer ownership first.
- **A member cannot rename a project:** project identity requires owner or admin.
- **A viewer cannot create a key:** key creation is a builder mutation.
- **An old key still works after role removal:** revoke or rotate it separately.
- **A team member cannot leave:** owners and sole members have protected restrictions.

Related pages: [Invite and manage a team](/docs/administration/manage-a-team),
[Activity and audit history](/docs/operate/activity-and-audit), and
[Evaluation credentials](/docs/evaluate/credentials).