Organization admin branch — Tenantx kernel

The organization admin area is a second shell inside the same tenant app: same login and SidebarProvider, but a different sidebar and route subtree for org-wide work (all workspaces), as opposed to workspace-scoped settings under /settings/….

How the UI switches

PersistentLayout chooses the sidebar from the path:

• Paths starting with /org-admin → OrganizationAdminSidebar
• Everything else in that layout → SmartSidebar (tenant “branch” workspace app)

So “org-admin branch” is literally URL-driven layout, not a separate React app or host.

Who can see org admin?

Frontend gate: canAccessOrganizationAdmin(profile, permissions) in frontend/src/organization-admin/lib/access.ts.

Roughly:

1. Workspace-only Spatie role admin → cannot open org admin (they stay in workspace-scoped tenant UI).
2. organization_admin or platform_admin (profile role string) → can access (subject to routes still using PermissionRoute where needed).
3. Otherwise: user must have org-wide workspace access profiles.workspaces_access_all === true and at least one of organizations.read, dashboard.read, workspaces.read in their effective permission list.

Post-login defaulting: shouldDefaultToOrgAdminArea may send certain users to /org-admin first when they have no default workspace, org-wide access, and the right role/permissions (see the same file).

Enterprise/plan checks may further affect redirects elsewhere; the access helper is the single source for “show org-admin sidebar entry”.

What lives under /org-admin?

Typical kernel routes (see frontend/src/App.tsx):

• Dashboard, subscription (plans, renew, fees)
• Organizations — only the current organization, edit-only in the kernel (no tenant API create/delete; see OrganizationController::store / destroy and OrganizationsManagement when pathname.startsWith('/org-admin'))
• Workspaces (branding), users, profiles, permissions, roles, user-permissions, activity logs
• Link back to main app (/dashboard)

Menu items are permission-gated (useHasPermissionAndFeature, etc.) like the rest of the app.

Org admin vs tenant “Settings” sidebar

Product copy should say workspace where the UI means workspace; APIs may still say workspace_id / workspace_branding.

API and workspace context

• Org-admin pages call the same tenant API as the rest of the app (auth:sanctum + organization middleware, plus subscription:read / subscription:write where routes require it).
• Routes that need a current workspace use workspace.context middleware and getCurrentWorkspaceId($request) on the server. Org-wide screens may not attach workspace context; do not assume current_workspace_id exists on every org-admin request.
• Workspace switching (header / context strip) still applies when workspaces_access_all is true: the client sends workspace_id for scoped API calls.

Authorization reminders

• Org admin is still a tenant user with profile.organization_id set. Spatie checks use team = that organization.
• Platform operators use subscription.admin and /platform — see PLATFORM_ADMIN.md. Do not use tenant hooks to authorize platform pages.

Related docs

• TENANCY.md — organizations vs workspaces.
• PERMISSIONS.md — teams, workspace-scoped roles.
• PLATFORM_ADMIN.md — global operator surface.