Organization

The Organization page (/organization) manages who belongs to your organization, what they can do, and invitations that haven’t been accepted yet. Membership itself is not a Switchbench concept: it’s delegated entirely to Logto OSS, the identity provider every Switchbench service trusts (see the platform’s Logto architecture doc for the full picture). The dashboard never stores its own copy of who’s a member or what role they hold — every list on this page is read live from Logto through the BFF.

Roles and what each can access

Every organization member is assigned one or more Logto organization roles: Super Admin, Operations Admin, Security Admin, Developer, Compliance, and Standard User. These are seeded in Logto, not defined in Switchbench code — an organization’s actual role list, shown wherever this page displays roles, is whatever Logto returns for it.

Under the platform’s current (MVP) authorization policy, every signed-in member of an organization can reach the same platform scopes — API keys, KMS keys, behaviours, certificates, engine config, routing rules, audit log — regardless of which of the six roles they hold. Member management and product trials are the two exceptions. Starting a product trial (products:manage) is also admin-only, and its Start trial button is disabled for other members. Member management is all-or-nothing. Reading members, roles, and invitations — and inviting, changing another member’s roles, removing a member, or revoking an invitation — all require the Super Admin or Operations Admin role specifically. A member without one of those two roles doesn’t get a read-only view of this page: every request it makes (members, roles, invitations) is rejected, so the page shows a load error instead of any membership data. Because of this, an organization should always keep at least one member in one of those two roles — the platform actively enforces this: removing the organization’s last Super Admin/ Operations Admin, or replacing their roles with a set that drops both, is rejected outright (a 409 — “The last member with members:manage cannot be removed/demoted”), so this failure mode is prevented rather than merely discouraged. To demote or remove the last manager, first promote another member to Super Admin or Operations Admin.

The distinct role names beyond Super Admin/Operations Admin — Security Admin, Developer, Compliance, Standard User — exist today as an organizational label for who’s meant to be doing what, not as an enforced permission boundary; a future authorization pass may split platform scopes further along these lines.

Inviting a member

1. Click Invite member (visible only if you hold Super Admin or Operations Admin).
2. Enter the invitee’s email address.
3. Select at least one role to grant on acceptance — the dialog blocks submission with no role selected.
4. Submit. The invitation is created in Logto and its state is listed under Pending invitations until it’s accepted, revoked, or it expires (7 days after creation). An address that already has a pending invitation is refused, so revoke the existing invitation first if you need to resend it.

What the invitee sees

The invitation email links to /invitations/{invitationId} in the dashboard — a page reachable without an existing organization membership:

1. If the invitee isn’t signed in, the entry page (InvitationEntryPage) offers Create account or Already have an account? Sign in before continuing.
2. Once authenticated, the acceptance page describes the invitation — inviting organization’s name, who sent it, and the role(s) they’ll join with — and offers Accept invitation.
3. The BFF checks the signed-in account’s verified email against the invitation’s addressee before accepting; a mismatch shows This invitation is for <email>. You are signed in with a different account. with a way to sign out and switch accounts, rather than silently joining the wrong person.
4. An expired, already-revoked invitation, or one that’s already been accepted by someone else shows a specific message for that state instead of a generic error — there’s no decline flow; if the invitee lets it expire, an administrator needs to send a brand-new invitation (see below) rather than reviving this one.
5. Accepting adds the invitee to the organization with the invited role(s) and signs them in again, since a role/membership change only takes effect on a fresh sign-in.

Resend re-sends the invitation email without changing its expiry or roles — it exists for a link that was lost or never delivered, not to extend an invitation’s lifetime. It’s also only offered on invitations this page still lists as pending: once an invitation’s expiry passes, the Pending invitations table drops it from view entirely (it isn’t shown in some disabled or “expired” state), so there’s no Resend button left to click. Revoke invalidates the invitation link immediately. Either way, a revoked or expired invitation can’t be reactivated or renewed — the only way to invite that address again is Invite member with a fresh invitation.

Changing a member’s roles

Click Change roles on a member’s row (visible only with Super Admin or Operations Admin) to open the role picker and replace their full set of roles. This is a full replacement, not an incremental add/remove — the roles you leave unchecked are removed. A role change takes effect the next time that member’s session issues a new access token (their next sign-in, or their next silent token refresh); it isn’t retroactive to tokens already issued. If the target is the organization’s only Super Admin/Operations Admin and the new role set drops both, the change is rejected — see Roles and what each can access above.

Removing a member

Click Remove on a member’s row, then confirm — the membership itself is removed immediately and is not reversible from this page (re-invite them to restore access). If the target is the organization’s only Super Admin/ Operations Admin, the removal is rejected instead — see Roles and what each can access above.

A successful removal stops the member from signing in to the organization again or refreshing their session for it, but it is not an instant kill switch on access they already hold: Switchbench validates Logto-issued JWTs locally against Logto’s JWKS, with no introspection call on the request hot path (see Identity: Logto OSS), so an access token issued to that member before the removal keeps working against every service it’s valid for until it expires (up to its 1-hour access-token TTL) — the same non-retroactive-token behavior described for role changes above. Removing a member only revokes their access to the organization; it does not touch anything they created. API keys, client certificates, behaviours, and every other org-scoped resource are owned by the organization (org_id), not by the member who created them — there is no per-user ownership field on any of these records — so a removed member’s API keys keep working, their issued certificates keep authenticating traffic, and their configuration changes stay in place until another member with the right access explicitly changes them.

See also

• API Keys and Certificates — the org-scoped resources a removed member’s actions leave behind.