Admin follow-up contextMembers
You navigated here via the admin Week 8 readiness summary. Continue the targeted onboarding, billing, verification, or go-live review for this workspace, capture the outcome on that surface, then return to the filtered admin readiness view. This is navigation-only context and does not change identity, impersonate a member, or automate remediation.
Audit export continuity
Reuse the same Latest export receipt from /settings so the filename, filters, and SHA-256 stay chained from settings through verification, go-live, and back into this admin handoff. This manual evidence relay is navigation-only; open the receipt, carry the proof in the workspace surfaces, and then return here to complete the queue or readiness loop.
Current workspace: default · Week 8 focus: Billing warning
Treat this as the manual admin → workspace surface → admin loop: follow the requested surface, capture evidence or outcome notes there, then use the return link below to restore the admin context and keep the focus state aligned.
Returning keeps the same admin filter state in place so the operator can continue the governance review without rerunning the drill-down manually.
Workspace access
Review member roles, seat reservation pressure, and onboarding posture for the selected workspace.
First-team guidance
Start your workspace governance by inviting at least one viewer (for audit and verification), one operator (for run/integration tasks), and, if approvals are required, a legal/approver role. Spread these roles out so the first run and billing checks can be validated without overloading a single inbox. Keep the workspace owner slot for the person managing plans and billing actions.
Once the first members accept via /accept-invitation and complete onboarding, each membership is tied to a workspace and a role; you can adjust the role later if operational needs change.
Pending invitations reserve member seats before acceptance, so seat pressure can show up here before a new teammate ever reaches onboarding or usage follow-up.
In this slice the invitation handoff is self-serve: create the invite here, copy the one-time token, and share it through your existing channel. Delivery itself is not automated inside the product yet.
Manual onboarding handoff
Walk the newcomer through this manual lane: 1) generate the one-time token in this form, 2) send it through your own channel, 3) invitee redeems at /accept-invitation, 4) they switch into the workspace, then 5) follow the per-role action lane to continue onboarding, billing, verification, or go-live.
None of the steps here send email or impersonate another user; they keep everything manual but trackable in the workspace context.
Workspace members
Role and status visibility for the selected workspace.
Who to invite first
A viewer keeps verification evidence readable, an operator handles the first run / plan checks, and an approver covers the legal gate if you need approvals before going live. Adjust roles later once the workspace has real usage or billing evidence.
Status semantics
`active` means the person can continue through their assigned lane now. `pending` or `invited` means the self-serve handoff is still incomplete. Any other state should be treated as historical or requiring manual review before the workspace relies on that access again.
Audit export continuity
Governance roles should reopen the Latest export receipt from /settings?intent=upgradeso the filename, filters, and SHA-256 stay linked to verification, go-live, and the eventual admin handoff.
This is a navigation-only manual relay; the links keep workspace context intact but do not auto-attach the receipt or finish rollout steps on your behalf.
Loading members...
Invite member
Self-serve invite lane
Create the invite, hand off the one-time token, then let the recipient redeem it in their own browser session. After redemption, they can switch directly into this workspace and continue along the role lane that fits them.
Trusted session reminder: invite redemption should happen from the recipient's authenticated SaaS session, not from a borrowed browser or fallback-only local context.
Selected lane: Viewer
Role guidance
- Viewer: Best for audit reviewers and people who only need read access to evidence and usage posture.
- Operator: Best for the person running the first demo flow and keeping verification notes current.
- Approver: Best for legal or policy sign-off before the mock go-live drill is treated as ready.
- Workspace admin: Best for the teammate coordinating members, settings, and credential readiness.
This flow is self-serve. A one-time token is revealed in the browser and you share it through your existing channel; the product does not send email for you in this slice.
Manual invite checklist
Copy the token, send it manually, remind the recipient to redeem it at /accept-invitation, then confirm the workspace switch and follow the role lane you just assigned.
This keeps the entire onboarding path traceable without relying on email automation or support tooling.
The recipient should redeem from a trusted SaaS session that matches the invited identity, then re-open /session before continuing into onboarding, usage, verification, or go-live follow-up.
Pending invitations count against the workspace seat reservation until they are accepted, revoked, or expired.
Current role lane: Viewer lanes usually start in Verification and Artifacts so evidence can be reviewed before any broader change is requested.
Invitations create pending access records first, reserve a seat immediately, then convert into memberships after acceptance.
Invitations
Track pending, accepted, expired, and revoked invitation state.
Invitation lifecycle
When you create an invitation, a one-time token appears for copying; it is not retrievable later, so paste it into the onboarding note before closing the form. Invited users redeem the token at /accept-invitation. Revoke removes the pending record so the token can no longer be used; already accepted memberships stay active and must be manually deactivated if access should stop.
This panel tracks the self-serve handoff only. It does not confirm external delivery over email or messaging tools.
Pending invitations also reserve member seats until they are redeemed, revoked, or expire, so seat pressure can block additional invites before a new member accepts.
After the token is accepted, double-check workspace context and then follow the appropriate role lane (verification for viewers, playground for operators, go-live for approvers, etc.).
Treat acceptance as a trusted-session checkpoint too: if the invitee lands in the wrong workspace or role, send them to /session before they touch onboarding, usage, verification, or go-live follow-up.
Loading invitations...
Pending
Recent history