Recording an observation for the platform to rule on.
A user who belongs to exactly one organization appears to have no UI path to the workspace management pages (/organizations/<slug>/members · /invitations · /settings). Three mechanisms that are each individually reasonable close every door at once:
/organizations auto-skips. Deliberate, and documented as such:
UX P0-1: auto-skip the picker when the user belongs to exactly one organization. […] We still mount the page (so direct navigation to /organizations works) but redirect once orgs have finished loading.
(packages/app-shell/src/console/organizations/OrganizationsPage.tsx)
Confirmed empirically: with one org, GET /_console/organizations lands on the last app page; after creating a second org, the same URL renders the picker.
The workspace switcher is hidden with a single org. Verified: the top bar shows no workspace control until the user has ≥2 organizations, at which point the switcher (with its Manage members item) appears. Sensible on its own — but it is the only entry point to the manage pages.
The avatar menu has no "My Organizations" item. The comment right above the auto-skip explains that this is what should reopen the picker:
Two deliberate ways to reach this page (vs the auto-skipping post-login redirect): ?manage=1 (avatar menu "My Organizations") shows the picker; ?create=1 (avatar menu "Create workspace") additionally opens the create dialog directly. Both suppress the single-org auto-skip below so a single-org user can actually reach "New organization" / the dialog.
Observed avatar menu (zh, both a single-org and a two-org user): 个人资料 / 创建工作区 / 主题 / 语言 / 注销. 创建工作区 is the ?create=1 entry and works; there is no?manage=1 entry.
Net effect: a single-org owner cannot reach Members / Invitations / Organization settings without hand-typing /_console/organizations?manage=1. Inviting still works from Setup → Users → Invite user, so the workspace is not unusable — but role changes, invitation cancellation, renaming the org and deleting it are all only in those pages.
The decision
Either restore the ?manage=1 avatar-menu item the comment describes, or show the workspace switcher unconditionally (a one-org switcher is a bit redundant but carries Manage members), or point Setup at the manage pages. If single-org users are intentionally not meant to reach these pages at all, the stale comment should go instead.
Environment
Local dev server http://localhost:8080, multi-org enabled, zh locale, observed 2026-08-12. The server was started by the maintainer and its exact commit is not verified; the source quoted is the current objectui main checkout.
Recording an observation for the platform to rule on.
A user who belongs to exactly one organization appears to have no UI path to the workspace management pages (
/organizations/<slug>/members·/invitations·/settings). Three mechanisms that are each individually reasonable close every door at once:/organizationsauto-skips. Deliberate, and documented as such:Confirmed empirically: with one org,
GET /_console/organizationslands on the last app page; after creating a second org, the same URL renders the picker.The workspace switcher is hidden with a single org. Verified: the top bar shows no workspace control until the user has ≥2 organizations, at which point the switcher (with its Manage members item) appears. Sensible on its own — but it is the only entry point to the manage pages.
The avatar menu has no "My Organizations" item. The comment right above the auto-skip explains that this is what should reopen the picker:
Observed avatar menu (zh, both a single-org and a two-org user): 个人资料 / 创建工作区 / 主题 / 语言 / 注销.
创建工作区is the?create=1entry and works; there is no?manage=1entry.Net effect: a single-org owner cannot reach Members / Invitations / Organization settings without hand-typing
/_console/organizations?manage=1. Inviting still works from Setup → Users → Invite user, so the workspace is not unusable — but role changes, invitation cancellation, renaming the org and deleting it are all only in those pages.The decision
Either restore the
?manage=1avatar-menu item the comment describes, or show the workspace switcher unconditionally (a one-org switcher is a bit redundant but carries Manage members), or point Setup at the manage pages. If single-org users are intentionally not meant to reach these pages at all, the stale comment should go instead.Environment
Local dev server
http://localhost:8080, multi-org enabled, zh locale, observed 2026-08-12. The server was started by the maintainer and its exact commit is not verified; the source quoted is the currentobjectuimain checkout.