How builtin and custom roles, teams, project overrides and environment assignments combine — and the one rule that surprises people.

Roles and access

Access is decided per organization, and narrowed from there. Nothing here is set on the person: the same colleague can be an admin in one organization and a viewer in another.

The four builtin roles

The viewer's deliberately small sidebar is Resources, Access requests and Activity. Use a custom role when a read-only person also needs one of the separately gated screens, such as the Dashboard, Pipelines, Jobs, Alerts, Approvals, Backups, Connectors or Compliance. Mutating controls remain unavailable without their permissions.

You can also define custom roles with an arbitrary set of permissions — Organization → Roles. A custom role holding every permission is exactly as capable as admin.

Narrowing: project, then environment

A member's organization role can be narrowed twice, and both live in one editor on the Team screen:

1. Per project — "an operator generally, but a viewer on the billing platform."

2. Per environment of a project — "an operator on QA and UAT, a viewer on Production."

Both are narrowings. An assignment can never grant more than the role it narrows: if you later lower somebody's project role, their environment assignments are intersected with the new one at request time, so nothing silently keeps a permission it used to have.

Teams can contribute the same project and environment grants to several members. Effective access is the union of the person's own membership and every team they belong to; the Explain action on a person shows each source instead of making an administrator add the grants up by hand. A team grant can widen a narrower grant from the membership or another team, which is why the explanation lists all contributing sources.

The rule worth reading twice

Once a project has any environment assignment for a member, every environment of that project that is not named becomes unreachable to them — including for reading.

This is not a bug and it is not a fallback to the project role. It is what makes the feature mean anything: "operator on QA" would say very little if it also left Production quietly readable and writable at the project role.

Two consequences follow, and the app announces both rather than letting you discover them:

• Adding a project to somebody's scope simultaneously removes them from every environment of it you did not name. The editor previews exactly what a change takes away and refuses to save silently when something would be lost.

• A new environment starts closed for every member who has an assignment on that project. The screen that creates an environment reports who now has no access to it.

If a member has no environment assignments at all, none of this engages and they behave exactly as before.

Ownership is not a role

Each organization has exactly one owner — the member responsible for the tenant. Deleting the organization and transferring ownership are the owner's alone; they are deliberately not permissions, so they cannot be granted by assembling a custom role.

If the Team screen says no owner is recorded (an organization created before ownership existed) or that the owner's account is revoked, both are stated with the fix, because neither can be resolved by anybody else.

Asking for access you do not have

Access requests is the self-service path for the case a role does not fit: somebody needs a database login, a scoped credential, or a standing permission for a reason worth recording, without being handed a role that can do everything else too.

An organization defines request types — what can be asked for, who may ask (by team), how long the access lasts (a fixed set of durations, or standing), and who approves. A type is disabled rather than deleted once it stops applying, so the record of what it was and who could ask for it is never lost.

Approval follows the same fallback chain as Production pipeline approvals: named people, then a team, then anyone holding the approval permission — with the requester always excluded, so nobody approves their own request. A type can be marked auto-approve for something genuinely low-risk (a read-only QA login), but that has to be chosen on the type; it is never the default.

Once approved, fulfilment runs as a background job and mints the access itself — a temporary database login, a scoped credential — rather than asking an administrator to go and create one by hand. A credential is revealed once, through its own permission, and the access is withdrawn automatically when the window closes (or immediately, if somebody revokes it early). Nothing about this needs mutate: asking for access is the one action a person with no access must still be able to take, so it is exempt from the router's usual mutating-request permission floor and gated only on holding request-access — which a narrow, no-mutate role can hold on its own.

Signing in

Sign-on is federated only — GitHub, Microsoft or Google, whichever your organization allows. There are no passwords to manage and no keys to paste. Security in the account menu shows the provider identities linked to the account, lets you enrol a fingerprint or device credential for re-sign-in, and holds this browser's idle sign-out setting. A device credential cannot create or link an account on its own; a federated identity establishes that account first.

Automation authenticates differently, by workload identity from your CI provider rather than by a long-lived secret.