Skip to content

0002 — Provisioning and onboarding UI gaps (admin-console / learner-web)

Status: candidate Opened: 2026-07-10 · Area: admin-console, learner-web (identity & membership surfaces) Reopen trigger: the first deployment where an operator must provision a real Organization/cohort without shell access to the database, or the first cohort that must be onboarded by invitation rather than self-serve joining.

Found while writing the v1 end-user docs (ADR-0051): the “no vaporware” rule required grounding every guide in shipped UI, and these in-scope flows have no UI surface (grep- and route-level confirmed, 2026-07-10):

  • Organization creation / first-run provisioning — admin-console only selects among existing Organizations (ScopeSummaryCard) and edits an Organization’s image/issuer profile. Nothing creates one.
  • Claim Token issuance or redemption — the domain concept exists (CONTEXT.md; pre-provisioned Persons rebound at redemption) but neither admin-console (issuance) nor learner-web (redemption) exposes it. Zero hits for claim-token surfaces in either app.
  • SIS / OneRoster import trigger — admin-console shows the consequences of imports (identity Correlation Review queues, resource-catalog curation) but has no way to start or monitor an import run.
  • Learner enrollment / direct Membership management — the only membership-granting admin action is the staff portal invite (teacher / assistant / observer / mentor / org-admin / platform-admin; no learner role). Learner-web onboarding is exclusively the self-serve Join offering button on the Offerings list (joinOffering in features/sync/lib/sync.tsx) — open joining, no invitation or roster-driven path.
  • Related loose end: root.nav.offerings i18n key exists in admin-console with no route behind it; Offering creation lives only in teacher-portal.

The v1 docs document the real paths only (staff invites; self-serve joining) and state the boundaries explicitly (“Portal invites provision staff and administrators, not learners”). Under the standards-driven-discovery rule these gaps are candidate features, not doc stubs — each needs its own product decision (e.g. is open self-serve joining the intended learner onboarding for v1, or a prototype convenience?). When any of these lands, its guide belongs in the matching docs area, and the corresponding “gap” wording in the affected guides should be revisited.