Shared work and HiveAI¶
HiveAI can help interpret shared work and prepare a proposed change. The work package, receiving workspace, people with access and recorded evidence still determine what the change means. An assistant answer does not grant access, transfer ownership or confirm that another workspace completed its work.
Availability: this is an explanation of the inspected implementation and its limits. It includes acceptance, execution, review and completion, but their complete assistant journeys still need verification. Sending, rerouting, rejecting, adding people and filing into Records have incomplete assistant connections at the inspected version. Use the corresponding dedicated feature guidance where available; do not rely on those five actions being usable through HiveAI. Connected assistant screens and deployed behavior remain unverified.
Understand what an answer covers¶
The assistant's Shared Work information can include visible packages, receiving destinations, possible participants, readiness for Records filing, exchange history and information needed to prepare a new package. These are separate questions with different limits.
| Information | How to interpret it |
|---|---|
| Visible work | A limited list of packages visible to the person asking. It is not an organization-wide inventory. |
| Receiving destinations | Options for the selected receiving workspace. A destination still needs to be valid when the change is made. |
| Possible participants | Active people matching the search, excluding people already participating. A short result does not prove that no other eligible person exists. |
| Records readiness | Whether the received package meets the inspected filing requirements, including a suitable primary document. Readiness is not a filed record. |
| Exchange history | A limited list of exchange events. Use the package's history and recorded evidence for a fuller investigation. |
| New-package information | Connected workspaces, published capabilities and receiving destinations. These describe choices, not a reservation or a promise that sending will succeed. |
An answer can be incomplete even when it contains useful information. Some results are capped without an explicit continuation or completeness warning. Refine the question and check the dedicated feature before concluding that a package, person, option or historical event does not exist. A current response can still contain an older package update.
Document names and readiness information do not mean that the assistant has opened or read the document. The protected document step has its own access checks. Keep sensitive information within the organization's authorized channels.
Review a proposed change¶
A proposed change is a preview. It has not yet performed the action. The intended governed process requires human approval; an instruction to prepare a change is not evidence that the change was approved or completed.
Before relying on a proposal, check the workspace, package, requested action and evidence. For lifecycle work, distinguish the stage being recorded from the result of that stage. An execution entry can record an unsuccessful outcome; a review can record rejection. See progress and evidence for the business meaning and prerequisites.
Prepared changes expire and can become stale. Access, suspension, the package or a receiving destination can change after information was read. A preview is not a guarantee that all later checks will pass. If the proposal is stale or access changed, refresh the package and prepare a current proposal through an available supported journey.
Assistant proposals do not currently support every correction and communication detail available to the underlying evidence process. Do not describe a fresh assistant entry as a correction of an earlier entry unless that relationship is explicitly supported and verified. Keep the original evidence reference for support.
Interpret a result and recover from uncertainty¶
A change can reach different parts of the platform at different times. A receiving decision may be recorded before the local package view catches up. Records filing can return a new record reference while the package's record link is still pending. Notifications and reporting may update later.
| Situation | Appropriate next step |
|---|---|
| Preview unavailable, stale or access denied | Check the workspace and package access, then obtain current information. Approval cannot override an unavailable capability or missing authority. |
| Saved result says the action completed | Compare the reported action with the package's current state and evidence. A saved result describes that attempt, not every later change or downstream delivery. |
| Decision or filing succeeded but the view is behind | Preserve the result and related work or record reference. Refresh and reconcile the original attempt rather than creating an unrelated second action. |
| Timeout, error or no saved result | Treat the outcome as uncertain. A receiving service may already have acted. Ask support to check the original attempt, exchange history and local evidence before repeating it. |
| Protected file step completed | Confirm the intended file and target in the dedicated flow. Completing upload or viewing does not establish that a package was sent or a record was filed. |
Keep the original conversation and action reference, the workspace, work package, approximate time and any related record reference. Avoid sharing access tokens or protected-step proof material. Support needs to identify which stage succeeded, which result was saved and which update is pending. Absence of a saved result alone is insufficient evidence that nothing happened.
Protected upload and viewing¶
Preparing a protected step gives the application a short-lived way to open the appropriate upload or document journey. Preparation itself neither uploads a file nor creates a completed viewing session. If it expires or the target changes, prepare a new step through a supported journey.
Upload completion checks the upload belonging to the current workspace and person, its intended use and its remaining validity. A completed upload is not a sent attachment. The inspected assistant send action does not take that uploaded file into the outgoing package. Use sending shared work to understand the separate file and sending responsibilities. Connecting a protected upload to an assistant-prepared package remains unfinished.
Viewing completion checks that the person still has access to the package and its document. It is not proof that the person read, understood, accepted or signed the document. See viewing the primary document for the intended dedicated journey and recovery.
For managers and administrators¶
Use Shared Work evidence and the final business outcome when assessing progress. Counts of assistant proposals, uploads or successful responses are not counts of completed work, delivered files or accepted records. Do not claim time savings or autonomous completion from the presence of these capabilities.
Apply the organization's HiveAI commercial, permission and governance controls in addition to ordinary Shared Work authority. An assistant capability does not expand package visibility or bypass the receiving workspace's policy. For participation and filing responsibilities, use people and access and adding received work to Records.
This draft explains the inspected boundaries. Connected assistant journeys, source refresh and the initial reader review remain open.