An internal admin surface for granting an existing Toko account the studio access so they can build and launch collections (redesigned 2026-07-07 per R58: account creation is never gated — studio access is the only beta gate, and it is granted to accounts that already exist). The admin looks the account up by User ID or principal; the account's own profile identity (name, avatar, User ID) is displayed, never admin-entered. The only admin-authored fields are a description of what they're here to build and optional internal notes. Follows the page shell: white is used only for the breadcrumb bar, the cards, and the list bar; the header, search and filters sit on the grey. Anton for headings, Mona Sans for everything else.
The flow (reordered 2026-07-20): the access list (01) is the home surface, reached from the Admin nav. + Grant studio access in its white context bar opens the grant page (03); granting confirms via modal (05) and, on success, closes back onto the list with the new row present. Revoke from a row asks the canonical red destructive confirm (06) first.
Follows build-mocks/style-guide/page-shell.md. Ruling: R58 in design-doc-review-2026-07-02.md; context: Design Documentation/WIP/beta-readiness-failsafes.md §3.3. Ties to the Beta "approved creators only" gate in the landing / trust copy. Profile identity per user profile.
01Accounts with access · the home surfaceThe entry point, reached from the Admin nav. Every account granted studio access: profile identity (name from their profile, User ID + truncated principal), what they're building, who granted it and when, and status. + Grant studio access sits in the white context bar (the style-guide add-button placement) and opens the grant page (03). Search and the status filter sit on the grey; the table is a white card with the white list bar attached as a footer band. Revoke moves a creator to Revoked — kept for the record, not deleted; the account itself is untouched (R58: accounts are never gated, only studio access is).
Everyone granted studio access. Grant new access, edit notes, or revoke.
Creator
Building
Granted
Status
Mara Okafor
usr_01H8R2K4FM9C · k1m9…7uvw
Mineral songbird collections (Crystal Birds)
q7w8…3xyz · 2 Jun 2026
Active
Night Market Studio
usr_01H9T6WQ3ZRV · f8a1…2klm
Lanterns, masks & charms — seasonal drops
q7w8…3xyz · 28 May 2026
Active
Deep Blue Collective
usr_01HFA8D2MK6P · c4d5…1abc
Generative deep-sea creatures
q7w8…3xyz · 19 May 2026
Active
Solara Works
usr_01HKX3B7QSTW · e9f0…3def
Sun Sprites — editioned art
q7w8…3xyz · 11 May 2026
Revoked
Showing 1–25 of 128
…
02Empty · nobody has access yetFirst-run state of the same page: the centred empty-state hero (style guide: max-width 920px, image + title + sub + CTA). The context-bar add button stays available; the filters and table are simply absent until the first grant exists.
Everyone granted studio access. Grant new access, edit notes, or revoke.
No creators yet.
During Beta, publishing is limited to approved creators. Grant studio access to an existing Toko account and they'll appear here — account creation itself is never gated.
03Grant studio access · account lookupOpened from + Grant studio access on the list (01). R58 flow: the admin looks up an existing account by User ID or principal. On resolve, the account's own profile identity (avatar, name, User ID) appears — read-only, never admin-entered. The admin authors only "what they're building" and internal notes, then grants (which confirms via the modal in 05). Cancel returns to the list. The side panel shows the resolved account and the grant summary.
Give a Toko account studio access so they can build and launch collections. During Beta, only approved creators can publish.
Find the account
The account must already exist — account creation is never gated (R58). Lookup accepts a User ID or a principal.
Mara Okafor
usr_01H8R2K4FM9C · k1m9…7uvw
Member since Mar 2026
Identity comes from the account's own profile (name, avatar, User ID) — it is never entered or edited here.
Helps the team understand the intent behind the access grant.
Internal only — never shown publicly.
Studio accessCreate projects and collections, and publish them. One entitlement — no sub-permissions.
04Lookup statesEverything the account lookup can return. The grant is unreachable until an account resolves. Errors live on the field — not in a banner. The old "display name required" validation is gone (R58): identity comes from the profile, so there is nothing for the admin to name.
Invalid format
That isn't a valid User ID or principal.
No account found
No Toko account matches this ID. The person must create an account first — creation is open to everyone.
Found · no profile name yet
Unnamed account
usr_01J0XQ7M2A4D · b3c7…9pqr
This account hasn't set a profile name. Granting still works — ask them to complete their profile so their collections aren't labelled by an unnamed account.
Already a creator
Mara Okafor
usr_01H8R2K4FM9C · k1m9…7uvw
Active
This account already has studio access (granted 2 Jun 2026). Open their row in the access list to edit notes or revoke.
05Confirm & grantedGranting access is an explicit, confirmed action. The confirm modal restates the resolved account (its own profile identity) and the access level. On success the confirmation shows one action only — Done (or ✕) closes the modal and you're back on the access list (01) with the new row present. No "grant another" from inside the modal: starting a new grant goes back through the list's context-bar button.
Grant studio access?
✕
Mara Okafor
usr_01H8R2K4FM9C · k1m9…7uvw
RoleCreator
Beta publishApproved
BuildingMineral songbird collections
They'll be able to create collections and launch drops. You can revoke access at any time.
Access granted
✕
Mara Okafor now has studio access. They've been notified and can start building.
Mara Okafor
usr_01H8R2K4FM9C · k1m9…7uvw
Active
06Revoke access · destructive confirmRevoking from a row (01) asks first — the canonical red destructive confirm from the style guide (Simple Modal Base, left-aligned): title names the action and target, red warning triangle beside the consequence text, ghost Cancel + red Revoke. Because the grant record is kept and Restore exists, the copy states what actually happens — no false "can't be undone". The second note answers the question an admin actually has at this moment: revoke is forward-only. Live collections and running vendors are untouched and keep taking claims, so no collector is affected by a decision about the creator. The counts are real, from the account's own record — a generic reassurance would be worthless here.
Revoke studio access · Mara Okafor?
✕
Mara Okafor immediately loses the studio — all of it. No creating, no editing existing Draft or Review work, no publishing or launching, and no controls for anything already running. Their account is untouched (accounts are never gated, R58) and the grant is kept in the list as Revoked. You can restore access at any time; they'll be notified either way.
Their live work keeps running. 3 published collections and 1 running vendor stay up, keep taking claims and keep settling revenue — collectors see no change. Nothing is withdrawn by a revoke; taking work down is a separate moderation action. Because the studio controls go too, winding that vendor down becomes ours to do.
07Edit notes · the row’s pencilThe only two things an admin ever authored are the two things this modal edits — what they’re building and internal notes. Identity stays read-only at the top, because it belongs to the account’s own profile and is never admin-entered (R58). Editing notes is not a change of access: no role moves, nobody is notified, and the modal says so rather than leaving the admin to guess. Available on Active and Revoked rows alike — the record stays maintainable after a revoke.
Edit notes · Mara Okafor
✕
Mara Okafor
usr_01H8R2K4FM9C · k1m9…7uvw
Active
Shown in the access list so the team can scan who's here for what.
Internal only — never shown publicly and never shown to the creator.
Notes only. Access is unchanged and the user isn't notified — use Revoke or Restore to change what they can do.
08Restore access · confirm & restoredThe row action on a Revoked row, and the counterpart to 06. Restore is additive, not destructive, so it takes the neutral confirm — dark primary button, no red, no warning triangle. It still confirms rather than firing on click, because it hands back the ability to publish. The restored account returns to Active on the same grant record; no second record is created, so the list keeps reading as one audit trail per account.
Restore studio access · Solara Works?
✕
Solara Works
usr_01HKX3B7QSTW · e9f0…3def
Revoked
AccessStudio access
Revoked14 Jun 2026 · q7w8…3xyz
ReasonRepeated policy warnings
They'll be able to create collections and launch drops again, immediately. The existing grant record returns to Active and keeps its history; they'll be notified.
Access restored
✕
Solara Works has studio access again. They've been notified and their row is back to Active.
Solara Works
usr_01HKX3B7QSTW · e9f0…3def
Active
09Revoked record · the audit trailOpening a Revoked row. Because records are kept and never deleted, the list doubles as the audit trail — this is where that trail is legible: who granted, who revoked, when, and the notes as they stood. Everything is read-only except the two note fields (07). The account itself is untouched and stays fully usable for claiming, wallet and marketplace (R58) — stated on the page so nobody reads "Revoked" as "banned". Restore access is the primary action and routes through 08. The capability matrix is the load-bearing part: it now covers live work as well, because revoke is forward-only — published collections and running vendors keep going, and only new creation and publishing stop.
