---
title: Organizations and roles
description: Every permission in Izri is organization-scoped — the four roles, the scopes each one grants, and what that means for tokens.
order: 30
---

# Organizations and roles

**All permissions in Izri are organization-scoped. There are no global user roles.**

Being an owner of one organization grants you nothing in another. Every capability is gated through your membership role in the specific organization that owns the resource.

## The four roles

| Role | Intent |
| --- | --- |
| `OWNER` | Full access, including billing and destructive operations. |
| `ADMIN` | Everything operational — projects, runs, webhooks, tokens — but not org-level ownership. |
| `MEMBER` | Day-to-day contributor. Can read projects and trigger runs. |
| `VIEWER` | Read-only. |

New members default to `MEMBER`.

## What each role can do

Permissions are expressed as scopes. These are the defaults per role:

| Scope | OWNER | ADMIN | MEMBER | VIEWER |
| --- | :-: | :-: | :-: | :-: |
| `projects:read` | ✓ | ✓ | ✓ | ✓ |
| `projects:write` | ✓ | ✓ | | |
| `projects:delete` | ✓ | ✓ | | |
| `tests:read` | ✓ | ✓ | ✓ | ✓ |
| `tests:run` | ✓ | ✓ | ✓ | |
| `analysis:read` | ✓ | ✓ | ✓ | ✓ |
| `analysis:run` | ✓ | ✓ | | |
| `webhooks:read` | ✓ | ✓ | | |
| `webhooks:write` | ✓ | ✓ | | |
| `org:read` | ✓ | ✓ | | |
| `org:write` | ✓ | | | |
| `org:members:manage` | ✓ | | | |
| `costs:read` | ✓ | ✓ | | |
| `tokens:read` | ✓ | ✓ | ✓ | ✓ |
| `tokens:write` | ✓ | ✓ | | |

`OWNER` holds the `*` scope, which grants everything — including anything added in future versions.

The practical line between `MEMBER` and `VIEWER` is `tests:run`. A member can trigger a run; a viewer can only read the results.

## Roles cap what a token can do

An API token can hold **a subset of its creator's role scopes, never more**. A `MEMBER` cannot mint a token with `projects:write`, even deliberately.

This means a token's power is bounded by the role of the person who created it, at creation time. Changing someone's role does not retroactively expand tokens they already minted — reissue them.

## The runner scope

`runner:write` is server-to-server only. It exists so the runner service can move test runs through their lifecycle, and it is never offered when creating a token through the UI — it's minted out-of-band as part of runner deployment. If you're self-hosting, this is the credential the runner needs.

## Related

- [API tokens](/docs/configure/api-tokens) — minting and scoping.
- [Projects](/docs/configure/projects) — what organization membership gets you access to.