Organization settings
Seats, roles, and enterprise SSO status live here; integration credentials are provisioned via env (docs/ops/env-provisioning.md), never from this screen.
OIDC single sign-on
Configured against issuer https://core.codezero2pi.com · 7 IdP groups mapped onto Ruh Design roles (deny-by-default: unmapped identities get no role and no seat).
Sign-in entry: the Sign in surface. The client secret stays server-side and is scrubbed from every error surface.
Seat administration
Roles on this screen are Ruh Design roles(owner, admin, planner, product manager, estimator, sales, viewer) — a seat’s role scopes what it can do inside Ruh Design. This is a different axis from a member’s organization membershipon Ruh Core (admin / member / viewer), which governs org-level administration. Where a control below says “admin” it means the Ruh Design admin role.
| Seat | Identity source | Ruh Design role | Status | Actions |
|---|
Federated (SSO) seat changes are written THROUGH Ruh Core (role via a product grant, enable/disable via org membership) as you, the acting admin — Core enforces the seat cap and the last-admin/self-change guards, and its refusals are shown here verbatim. On the seat's next Sign in with Ruh, the IdP group map (RUH_DESIGN_SSO_GROUP_ROLE_MAP) re-derives its role. Local demo seats are managed locally with the same guards.
Seats used across the organization
Each active member with a product grant consumes one seat. At the cap, the next invitation or role grant is refused with SEAT_LIMIT_REACHED — free a seat or raise the plan limit first. The count matches what Ruh Core enforces.
Invite members by email
| Invitee | Role | Status | Expires | Actions |
|---|
Project workspaces
| Workspace | Created | Status | Actions |
|---|
Archiving hides a workspace from the project rail; its registry entry and state file are never deleted, so an operator can always recover it from data/workspaces.json.