Session and workspace access
Confirm the current SaaS identity, the active workspace context, and which workspaces this console session can reach.
Context check
This surface spells out who you are, where you are, and what role/tenant the console is using. Treat it as the launch pad before going into onboarding, billing, verification, or the go-live rehearsal so those panels see the workspace you expect.
Active workspace: default · Reachable workspaces: 1 · Context source: Environment fallback (non-production)
If anything looks off, identity, tenant, workspace, or roles, use the Session access panel below to revalidate before continuing.
Admin readiness handoff is active for this workspace, so keep this session context aligned before you return to the Week 8 readiness view.
Before entering a managed lane
Treat this page as the Week 3 checkpoint for all managed SaaS follow-up. Confirm the current workspace, accessible roles, and context source first, then continue manually into the right lane for the job at hand.
Trusted session guidance: only metadata-backed SaaS session context should be treated as a trusted launch point for members, onboarding, usage, verification, or go-live follow-up. If this page is showing fallback or local-only context, stop here and re-check the signed-in workspace session before recording evidence or changing access.
These links only preserve the current console context. They do not impersonate another user, change workspace access, or trigger support-side remediation.
Operator checkpoint sequence
Use the same manual sequence each time: 1) confirm identity and role scope, 2) confirm the active workspace and tenant, 3) confirm whether fallback/local-only context warnings are present, then 4) continue into the next lane that matches the task.
This keeps onboarding, billing, evidence capture, and go-live notes attached to the right workspace without pretending the console can auto-correct a wrong context after the fact.
Why this page matters
The SaaS plan depends on server-side session resolution instead of trusting arbitrary tenant input from the browser. This page is the closest operator-facing checkpoint for that contract: verify identity, workspace, tenant, and reachable workspaces here before you create credentials, review billing posture, or attach evidence.
If the current context is wrong, stop here and switch workspaces first. That is safer than correcting evidence, keys, or go-live notes after they land on the wrong workspace.
Session identity
This view shows the identity and workspace context currently active in the console.
Workspace context control
Use workspace switching here on the session surface, then continue into onboarding, billing, verification, or go-live once the context looks correct.
User
console@govrail.net
console@govrail.net
Auth provider
workspace_context
Subject: console@govrail.net
Current workspace
Default Workspace
default · ws_env_default
Tenant
tenant_demo
Roles: platform_admin
Workspace context was loaded from environment fallback values. Use metadata-backed session context before production rollout.
This page is only a visibility surface. It does not impersonate another user, change roles, or open support automation.
Manual context checklist
1) confirm identity and role scope, 2) confirm the active workspace and tenant, 3) confirm the context source is the one you expect, then 4) continue into onboarding, billing, verification, or go-live.
If any of those are wrong, switch workspaces first or stop here before creating credentials, changing settings, or attaching evidence to the wrong workspace.
Audit export continuity
Trusted metadata sessions should reuse the same Latest export receipt from /settings (filename, filters, SHA-256) before moving into verification, artifacts, or the go-live lane so the downstream evidence chain stays tied to one manual thread.
Navigation-only manual relay: these links keep the workspace context intact but do not auto-attach the audit export or resolve rollout steps for you.
Workspace governance lane
Owner and admin roles should confirm identity, workspace scope, and tenant first, then move into members, settings, and credential readiness.
Session safety signals
Workspace context was loaded from environment fallback values. Use metadata-backed session context before production rollout.
This session context is local-only, so treat it as a manual preview checkpoint rather than a fully metadata-backed access proof.
Workspace access
Review which workspaces the current session can reach, then use the topbar switcher to move between them.
Loading session access...
Default Workspace
default · ws_env_default
How to use this
Use this page to verify identity and workspace reach before onboarding, billing, verification, or go-live follow-up. Use the workspace switcher in the topbar for actual context changes.
Changing the workspace remains manual. This page does not edit membership, elevate access, or impersonate a different user when you move between workspaces.
Role-aware next lanes
Use this page to confirm the right user, tenant, workspace, and roles before heading into Onboarding, Billing, Verification, or the Go-live drill. That keeps those routes safe and traceable.
The actions here are recommendations only. They help the operator pick the next manual lane, but they do not alter access or perform any support-side task.
All context changes remain manual here; nothing impersonates another role or runs support automation.