Use the Platform staff assistant¶
The Platform staff assistant helps authorized staff understand platform information and prepare controlled changes. Use it to investigate a specific issue, review the evidence and decide what to do next. Its answer is assistance; the owning console and the saved operation result remain the places to verify what actually happened.
Availability: this is a guide to the intended experience and the implemented backend rules. The inspected design shows a tenant-suspension review. The complete frontend journey, confirmation and recovery screens, and environment delivery remain unverified. Where a control is not yet available, use your established authorized Platform Console workflow.
Who can use it¶
An active platform staff account and the appropriate staff role are required. The assistant uses the current staff identity. It does not let you borrow another person's role or continue under authority you have lost.
| Reader or role | What this means |
|---|---|
| Platform staff with viewing access | Can use the staff-assistance entry point and permitted reads. Individual sources can impose additional access checks. |
| Support staff | Can prepare supported tenant actions, including suspension, reinstatement and starting export or deletion workflows, subject to the source's own rules. |
| Billing staff | Can prepare supported plan, pricing, quote, contract and tenant billing changes. |
| Platform administrators | Can prepare the more sensitive staff, account, deprovisioning, export/deletion control, analytics-cache and HiveAI governance or Support-publication actions. |
| Tenant administrators and everyday users | Do not gain platform staff access through their organization role. Use your organization's tools or contact authorized support. |
| Managers and executives | Can use this guide to set responsibility and review expectations. The guide itself grants no product access. |
Platform administrators include the lower staff access levels. A permitted assistant tool still has to satisfy the affected service's current rules.
Choose a clear request¶
State the issue, the organization or record involved, and the outcome you want. Include only information appropriate for the authorized platform workflow.
For example, “Review the service-health information for this tenant” asks for an investigation. “Prepare a suspension for this tenant because of the verified incident” asks for a proposed change. Neither statement should be treated as evidence that a change has happened.
Check the target carefully when organizations have similar names. A tenant-specific request must stay attached to that tenant. A platform-wide change, such as a plan-definition update, belongs in a request without a tenant target.
Do not put passwords, access tokens, setup tokens or other credentials into chat. Protected steps belong in their secure console flow.
Understand saved conversations¶
Conversations and their messages are saved for the staff member who owns them. A request can be accepted before its execution finishes, so leaving or reconnecting to the page does not establish whether the work stopped.
Saved history is not currently reliable model memory. The inspected implementation sends the current input to the model without the earlier conversation history. Some follow-up answers also lack the original question's context. Make a fresh investigation request self-contained. If the assistant loses context during a pending action, check that action's status before starting a replacement.
A missing item in a paged conversation list does not prove it was deleted. Complete, consistent history paging still needs qualification. Retain a safe conversation or request reference when investigating a problem.
Understand what the assistant can inspect¶
The backend has tools for tenant and user information, staff records, plans and pricing, billing workflows, quotes and contracts, usage, operational health, audit/security information, exports and deletion, the Support library, HiveAI governance and metrics, and business insights.
These tools return selected information, often for a time range or a limited page. An empty or short answer is not proof that no other records exist. Check the time range, filters, permissions and the owning console before making a business decision.
Support-library and business-insight tools have additional role requirements. A broad question does not override those requirements or turn all platform information into public information.
Review the intended tenant-suspension screen¶
The inspected design is headed Review a tenant suspension. It shows the current staff member and role, the target tenant, its current state, the reason, the expected effect, the source-check information and the review deadline.
Use that intended screen as follows:
- Confirm that the staff identity and target tenant are correct.
- Read the exact proposed change and reason. Check the expected effect against the tenant's current situation.
- Check the source information and review deadline. Refresh and request a new review if the information is stale or the proposal has expired.
- Select Continue in secure review only when the displayed proposal is the one you intend to review.
- In the protected workflow, inspect the exact action again and complete any required identity check using that workflow. Never send the credentials through chat.
The button is visible design intent. Its complete confirmation journey has not been verified, and the current backend does not establish a generic suspension-review handoff behind it. Do not interpret the button, a preview or an assistant message as a completed suspension.
The names, tenant and time shown in the design are examples. They are not live platform records.
Decide on one exact proposal¶
The backend prepares one pending step at a time. An action proposal is tied to the current staff authority, target and reviewed source information. Approval applies to that exact proposal.
Approve only when you understand the change. Reject it when the target, reason, effect or requested values are wrong. Rejection does not apply the proposed change. A changed source or changed staff authority can prevent an earlier proposal from continuing.
Proposals currently have a ten-minute decision window. Navigation and protected-step references normally have five minutes. Use the deadline shown for the actual request; do not infer it from an old screenshot or an earlier request.
The present backend preview can contain raw technical values and may fail when the preview is too long. A readable summary, complete details and reliable confirmation handling remain implementation work. If the preview is confusing, incomplete or fails to save, use the owning console and obtain the necessary review there. Do not approve details you cannot inspect.
Understand the available changes¶
These are supported preparation families in the backend, not proof that every corresponding frontend flow is delivered.
| Work area | Examples of proposed changes |
|---|---|
| Tenant support | Suspend or reinstate a tenant, change feature flags, start an export or deletion workflow. |
| Commercial administration | Create or revise plans and prices; advance a quote through its supported decisions; renew a contract; adjust a tenant's storage, trial or plan. |
| Accounts and staff | Deactivate or reactivate a user; create, revise or revoke platform staff access. |
| Sensitive lifecycle controls | Deprovision a tenant, cancel an export, or confirm or cancel a deletion workflow. |
| HiveAI operations | Publish, archive or delete Support guidance; manage governance policies, evidence, incidents and operational suspensions. |
| Business insights | Invalidate the supported insights cache under administrator authority. |
Each source owns its own prerequisites and consequences. Starting a deletion workflow is different from confirming it. Publishing Support guidance is different from completing its search activation. A commercial operation can have further billing or payment steps.
A proposed action can fail because the source state changed, the account is no longer authorized, a required record is absent or a provider is unavailable. Do not assume that changing the wording of the prompt makes an unsupported operation valid.
Open a destination or complete a protected step¶
Navigation is limited to known Platform Console destinations. A prepared destination means the assistant has asked the client to open it; it does not prove that the screen opened or that you can read its contents.
Protected steps include starting or ending an impersonation workflow, completing a stronger identity check and uploading Support guidance. Their completion must be checked by the server. A message saying “done” is not sufficient proof.
Use the secure console for the actual step and then return to the same saved request. If the request has expired or its authority changed, obtain a fresh review. Do not paste temporary links, tokens or credentials into the conversation to try to resume it.
The complete entry, completion and failure screens for these handoffs still need verification. A prepared protected step does not establish permission for unrelated work.
Read progress and final outcomes¶
| What you see or learn | What to do |
|---|---|
| Request accepted | Keep the request reference and wait for its saved status. Acceptance means the instruction was saved. |
| More information or a decision is needed | Respond to the current question or proposal before its deadline. Do not approve a stale copy. |
| Working | Avoid submitting the same operation as a new request. Check the saved status. |
| Completed | Read the result and verify the affected record in its owning console. For longer workflows, continue checking that workflow. |
| Partially completed | Identify what succeeded and what remains before taking another action. |
| Failed | Read the failure and inspect the source if work may already have been dispatched. A failure message alone is not a universal rollback guarantee. |
| Outcome uncertain | Treat the operation as unresolved. Ask support or operations to reconcile the original attempt before creating another. |
A lost connection does not turn an accepted request into a new request. Reopening status and resuming event updates are intended recovery actions; they should not start the operation again.
Recover from stale, missing or interrupted progress¶
If the page disconnects, return to the same conversation and saved request when that control is available. Check status before resending. If the update stream cannot resume, use the saved status rather than assuming no work occurred.
If a proposal is stale or expired, refresh the source, review the current details and prepare a new proposal only after establishing the original attempt's outcome. Do not reuse an old approval for changed values.
If staff access changes, the request may no longer be usable. Ask the responsible platform administrator to review your current assignment. Do not switch accounts to take over someone else's saved request.
If the assistant gives an incomplete answer after a clarification, return to the source record. The current continuation-context limitation can affect the answer even though the earlier conversation is still visible.
When asking for help, provide a safe request reference, approximate time, intended target, what you expected, the last visible outcome and whether you already approved or cancelled. Share restricted details only through the authorized support channel.
Cancel carefully¶
Cancellation is a request to stop this assistant turn. It is not an undo operation.
Before dispatch, cancellation can close a pending request. Once execution has started, the backend records cancellation while the operation can continue. It does not interrupt the already dispatched provider or source operation.
An unresolved outcome can also end up labelled cancelled without proving the source change was reversed. Always inspect the affected record or longer-running workflow before attempting the same change again. Use that workflow's own supported reversal or cancellation process if one exists.
Costs and information handling¶
Model work uses platform-internal AI cost accounting in this path. It should not be described as an ordinary tenant assistant wallet charge. A follow-up can involve another model run; saved responses and action decisions follow different paths.
An uncertain provider result can retain or conservatively settle reserved cost while the platform reconciles the original attempt. A failed answer does not necessarily mean no provider work occurred. This guide does not state prices or promise that staff assistance is free.
Some sensitive fields are omitted from tool results before they reach the model. This is a limited filter, not a guarantee that every confidential value or personal detail is removed. Keep requests appropriate for the platform's approved AI use.
Review responsibilities¶
Staff verify the target, requested change and final source result. Support investigates the original request before encouraging a duplicate. Managers and executives assign owners and escalation paths, and distinguish assistance from authoritative operational evidence.
The initial documentation reviewer is @she2. Product, audience and environment acceptance remain pending. No completion, deployment or security certification is implied by this local guide.
For related responsibilities, see Platform administration, AI governance and Support knowledge publishing.