Portal administration is not catalog work
The Platform Portal's /admin page is the control surface for partners, clients, instance requests, host grants, and managed hosts. Use it for onboarding and platform operations. Day-to-day product editing happens inside an assigned client workspace, not on this page.
A partner is the organizational boundary that owns clients and requests. A client is a tenant workspace. A host is the server that runs one or more clients. Creating a client does not create a server.
Who can do what?
| Role | Scope and responsibilities |
|---|---|
| SuperAdmin | Manages partners, clients, users, registered hosts, and host grants. Reviews instance requests, publishes independently approved requests, and operates managed hosts. Can use Delete record on eligible requests; that hides a record without deleting infrastructure. |
| PartnerAdmin | Works within their own partner. Creates clients on hosts explicitly granted to that partner, and creates/submits that partner's instance requests. Cannot grant hosts or approve requests. |
| ClientAdmin | Administers an assigned client workspace. Does not provision additional partner clients or manage shared platform hosts. |
| ClientUser | Uses an assigned client workspace. Does not administer partner or platform resources. |
ClientAdmin is not PartnerAdmin
A ClientAdmin operates inside an existing tenant; a PartnerAdmin onboards tenants under a partner. To give someone responsibility for multiple clients, use the authorized platform user-management flow to assign PartnerAdmin and the correct partner. Renaming a role or changing a display name does not grant permissions.
The server enforces both role and partner scope. A PartnerAdmin sees only their partner's records; visible or hidden buttons do not replace API authorization.
Remember me: seven-day sign-in
On the Platform Portal sign-in page, select Stay signed in for 7 days if you are using a device you trust. The seven-day period starts when sign-in finishes, including required multi-factor authentication (MFA). It is a fixed deadline: using the portal, refreshing a page, or opening a workspace does not extend it.
This setting remembers the session, not the MFA device. MFA is still required on every new sign-in. If you leave it unchecked, the existing regular session behavior remains in effect. Google or Microsoft sign-in follows the choice made on the portal sign-in page.
Signing out, revoking the session in Account & security, changing the password, or disabling the account ends the session sooner. For a lost or shared device, sign out and revoke its active session. Do not share session cookies or access/refresh tokens with support.
Open a client workspace
From Overview, choose Open workspace for an assigned client. The portal first selects that client and asks the platform to prepare the client-scoped workspace identity; it then hands the resulting workspace session to the PIM application. Portal authentication and workspace authentication are separate steps. A healthy portal session alone is not proof that the workspace handoff succeeded.
- Sign in to the portal and complete MFA if prompted.
- Confirm the intended client is listed and its host reports Running.
- Click Open workspace once and wait for the application to open.
- If it fails, read the displayed error and provide the operator its time, error code, and correlation/trace ID. Do not repeatedly switch clients or start/stop a healthy host.
The browser performs a cross-origin handoff from the portal origin to the API origin. The API gateway must allow the exact approved portal origin for this handoff. A blocked browser preflight (an OPTIONS request) returns before the authenticated workspace request is sent; this is a gateway/CORS configuration failure, not evidence that the user lacks a role or that the cell database rejected the user.
The fix for this incident was to add https://platform.tabgrid.io to the gateway's exact origin allowlist alongside the existing approved origins. It did not use a wildcard or weaken token validation. The cell separately needed its PostgreSQL provisioning transaction to run within its retrying execution strategy. Both layers must work for workspace access.
Workspace identity provisioning is idempotent and uses the signed platform handoff; it does not transfer a platform password. A workspace session is issued only after the client identity has been provisioned and the selected cell is ready. If the portal login succeeds but Open workspace fails, the platform operator should check the handoff preflight/origin, gateway route, cell readiness, and cell provisioning logs in that order.
Overview errors and client counts
The Overview inventory (client rows and counts) is loaded separately from workspace handoff. A failure to open one workspace must not label an already loaded client list as unavailable or replace its counts with loading dashes. Conversely, an actual client/partner inventory API error should be reported as an inventory error even when the workspace action has a different status.
If a client row is visible but the count or empty/error message looks inconsistent, reload once and distinguish the inventory request from Open workspace in the operator's network trace. A browser Failed to fetch message alone does not identify which API failed; check the request URL, HTTP status, response code, and correlation ID. Never send Authorization or Cookie header values.
Request list cleanup is separate from host deletion
The archive workflow is released in production and staging. SuperAdmin Delete record archives only Draft, Rejected, Launched, or LaunchFailed requests. SubmittedForReview/Pending, Approved, and Launching cannot be archived.
Archiving preserves immutable history/idempotency and leaves hosts, clients, and disks intact. Show archived requests retains partner scoping; archived Draft/Rejected records cannot be resubmitted or published. Archived failed requests still offer eligible SuperAdmin reconciliation and empty managed-host deletion.
Read the archive workflow and Delete record versus Delete host comparison. Delete host is destructive; Delete record is not. The startup timeout bounds failure reporting, not automatic relaunch or proof of repaired routing.
Find your way around /admin
- New partner: a SuperAdmin enters the partner name and optional billing email.
- New client: create a tenant on an existing host with available capacity. PartnerAdmins see only granted hosts.
- Request an instance: save a draft for a new managed host. Saving does not submit, approve, or launch it.
- Partner host grants: a SuperAdmin grants or revokes access to existing hosts for partner onboarding.
- Instance requests: review configuration, lifecycle, decision actors, reasons, history, and available actions.
- Partners: review records; SuperAdmins can edit details and activate or suspend partners.
- Clients: review state and assignment; SuperAdmins can edit settings, suspend/resume, or delete a client.
- Hosts: review type, endpoint, clients, and state. Managed-host controls include Start, Stop, and Terminate; termination requires zero clients.
Tables show API records, loading errors, and empty states. If loading failed, retry using the displayed control. An unverified table is not evidence that there are no records.
Grant an existing host to a partner
- As SuperAdmin, confirm the correct partner and the registered host in Partner host grants.
- Grant that host to the partner. Verify that the grant appears after the operation completes.
- Ask the PartnerAdmin to refresh New client and select the granted host with free capacity.
A host grant permits placement of new clients; it does not create a host, reserve capacity, or bypass host-state checks. A launched host is not automatically granted to the partner that requested it.
Revoking a grant removes that onboarding permission. Do not treat a grant change as client deletion or infrastructure termination; those are separate operations.
Choose the right workflow
- An existing host has capacity: follow Create a client and configure availability.
- New infrastructure is needed: follow Request, approve, publish, and grant a new instance.
- A launch is uncertain or failed: read Reconcile an existing host before considering deletion.
- An empty host should be removed: read the destructive-operation checklist.
- You are editing product records: start with the catalog user guide.
Troubleshoot access and missing controls
If you cannot create clients, check that the account is PartnerAdmin (not ClientAdmin), belongs to the correct partner, and has verified host grants. If controls differ, confirm the role, resource state, and deployed release rather than assuming access has been lost.
If a list will not load, resolve the displayed API error first. For Open workspace, share the request time, endpoint path, status, safe error code, and trace ID with your authorized operator. Share only the minimum necessary details; never post credentials, Authorization/Cookie values, refresh tokens, account records, private host endpoints, or customer data in a public support message.