Organization members & roles
Every person you invite to your organization holds exactly one role. The role decides what that person can do across your organization's tenants — and you can narrow or extend it per tenant. This page explains the four roles the portal offers, the special Owner role, and how tenants, groups and guardrails combine with them.
Where to manage it
Open your organization in the portal and use Members (change roles, grant tenants), Invitations (add people), Units (organize tenants) and, when enabled for your organization, the Groups, Policies and Guardrails panels.
The four roles
When you invite a member or change an existing member's role, the portal offers:
| Role | What they can do |
|---|---|
| Viewer | See everything — every resource service and your billing figures — but change nothing. |
| Member | Work with your resources: create, update and delete instances, storage, networks and all other resource services. Cannot manage members or invitations, and cannot change billing settings. |
| Billing | Full control of the money plane: billing profile, payment methods and invoices. Everything else is read-only. |
| Admin | Run the organization: full resource access, API keys, member and invitation management, tenants, units and audit logs. Cannot change billing settings and cannot transfer ownership. |
Two things people commonly expect that work differently:
- Admin does not include billing. An admin can read invoices and billing figures, but only Billing (or the Owner) can change payment methods or the billing profile. If your ops admin also needs billing control, see Groups below.
- Viewer really is read-only. If someone joins just to watch costs or review infrastructure, Viewer is the safe default.
- You manage members strictly below your own role. An admin can change the roles of viewers, members, billing, operator and developer users — but not another admin's or the Owner's, and not their own. If the Change role button is missing on a row, that row is at or above your level.
Owner
Each organization has exactly one Owner — set at creation. The Owner can do everything, including changing billing settings and transferring the organization. Ownership moves only through transfer ownership (Settings), never through the member list — that is why the role picker does not offer it. Roles are granted through invitations and changed on the Members screen by an admin or the Owner.
How a role decides access
Evaluation is default-deny and the same for every person:
- An explicit deny always wins.
- Otherwise an explicit allow grants the request.
- Reads are lenient: listing and viewing is generally allowed to every member; writes need an allow from the member's role (or an attached policy — see below).
This is the same policy engine that powers API-key access policies — people and machine principals are judged by one consistent model.
Per-tenant grants: scope a member to specific tenants
By default a member's role applies to every tenant in your organization. You can narrow that per member on Members → Grant tenants:
- All tenants (default) — the member works everywhere.
- Selected tenants — the member's tenant switcher lists only the chosen tenants, and their access is limited to those. Their role is unchanged inside the tenants they can reach.
Grants decide where a member's permissions apply. They never change what the role is — handing someone two different roles for two tenants is not something the portal offers today (see Combining permissions for the supported way to compose).
Groups: add permissions on top
A group carries attached access policies, and its members inherit them — on top of their role. This is the supported way to say "this person is also our billing admin":
- Keep the member's role as Admin (their day job).
- Create a group, attach a policy that allows the billing operations the person needs, and add them to the group.
Inside every tenant the member can reach, the group's permissions add to the role's; nothing else changes. The same mechanism scopes additional permissions per tenant: attach the policy with the tenant scope you want, and the group's members hold it exactly there.
Custom roles
Organizations can author custom roles — their own permission bundles, capped at the permissions the author themselves holds. A custom role is assigned when inviting a member (it appears in the invitation's role list); a member already holding one keeps it until moved back to a standard role. You cannot switch an existing member onto a custom role from the Members screen.
Guardrails: floors nobody inside can relax
An administrator can attach guardrails at the organization or unit (OU) level. A guardrail is a deny-only floor: it forbids a class of operations for everyone inside, no matter their role, group or policy. Use it for hard compliance lines ("no deleting instances in the production unit"). Guardrails restrict — they never grant.
Why was I denied?
The why-denied panel in the portal (under your organization) explains any denial: which rule answered, and whether it came from the member's role, a group policy or a guardrail. Every member can check their own permissions; admins can check another member's.
What is not available today
- Two roles for one member. One role per person; compose with groups instead.
- Permissions that follow an organizational unit. Unit-level guardrails bound everyone in the unit's tenants, but allow-permissions cannot be scoped to a unit — only to the whole organization or a list of tenants. Moving a tenant between units does not change any member's grants.