← Docs

Roles & permissions

Roles are your own

Every Organization defines its own Roles — there is no fixed, global role list. A Role is a named set of Permissions; a Membership assigns one Role to one User. A User can hold more than one Membership (more than one Role) at once. Manage this from the Roles & permissions page.

Two kinds of Permission

A Permission key like global:applications.manage gates this dashboard's own management API. An Application-scoped key like forge:billing.view is meaningful only to the Application that defines it — this dashboard's own Role editor never grants access to another Application's internal permissions, with exactly one carved-out exception below.

access_policy — gating who can sign into an Application

Every Application has an access_policy: open (default — any Organization member may sign in) or restricted. A restricted Application also requires the Role Permission <application-slug>:app.access — this one specific key is the exception mentioned above: it's auto-registered for every Application at creation time (so it can be granted in advance, before an Application is ever flipped to restricted) and it does appear in this Role editor's own picker, specifically so you can grant it here.

PATCH /api/v1/applications/{id}/
{ "access_policy": "restricted" }

The check happens when a code is issued (sign-in time) — revoking the grant takes effect on that person's next sign-in, not immediately on an already-issued token. That's deliberate: it matches how every other Permission change already behaves in this system. A revoked Session, by contrast, is invalidated immediately — the two are different kinds of event on purpose.

A narrower grant: API key scope

A real user's Role Permissions are one thing; a request authenticated with an API key is checked against that key's own, deliberately narrower scope too — a key can never do more than it was granted, even if its creator's Role gains broader Permissions later. Role Permissions themselves are unaffected by this; it only ever narrows what a specific key can exercise.

What's not built yet

There is no live, per-request re-check of access_policy or Permission grants against an already-issued token — only against the next sign-in.