Staging draft Work in progress · For review; coverage and acceptance incomplete

Accept, reroute or reject shared work¶

A decision tells the connected workspaces how the receiving workspace will handle a package. Review its purpose and destination before choosing an action.

Availability: These steps follow the inspected Final Screens. The backend implements the decision commands, but the inspected frontend still uses sample packages and unconnected action controls. This is an intended journey, not confirmation that it is available in your environment. Decision authority, recovery and some screen wording still require reconciliation before connected acceptance.

Choose the appropriate decision¶

Action	Use it when	Expected meaning
Accept work	The package is appropriate for your responsibility and can proceed	Records acceptance of this exchange. Further work, adding people or filing a record are separate actions.
Reroute	Another destination in the receiving workspace should handle it	Changes the package's current destination while retaining the original destination for context.
Reject	The receiving workspace cannot proceed with the package	Records a rejection reason and any explanatory note. It does not automatically prepare or send a corrected package.

Acceptance is not approval of the document's contents, completion of the requested work, a signature or an official Records filing. Rerouting is not a way to send the package to a different connected workspace. Rejection does not delete the package or automatically remove everyone who could already read it.

Before you decide¶

Open Shared work in the receiving workspace, then open the intended package.
Confirm its title, sending workspace, requested interaction and current destination. Read the summary and any available change note.
Review the primary document when your work requires it and access is available. A file name alone does not confirm that the document can be opened.
Check the current status and the actions shown on the detail page. Use your own account and your assigned responsibility; being able to read a package is not permission to decide its outcome.
Resolve missing or ambiguous context before submitting. The detail guide explains routing, access, history and Records readiness.

The intended pending-review view offers Accept work, Reroute and Reject to the responsible recipient. A colleague who can read the same package may have different actions. If an expected action is absent, ask the workspace administrator to check your responsibility and the package's current state.

Accept the package¶

Select Accept work on the package detail.
Read the Accept this shared work? confirmation. It explains that acceptance makes the next supported actions available.
Select Cancel to leave without submitting, or Accept work to confirm.
After a successful response, check the package again for Accepted and its history.

Expected result: Acceptance is recorded for the exchange. The intended accepted view offers Add people and Add to records where appropriate, but each has its own requirements. Do not assume that accepting has carried out either action or completed the work requested by the sender.

The package summary and history may not update together immediately. If a response is unclear, use the recovery guidance below before attempting another decision.

Reroute to the appropriate destination¶

Select Reroute on the package detail.
In Reroute shared work, use Search destinations to find the appropriate team, function or responsibility.
Review the destination's readable name and organizational context, then select it. Similar names can refer to different responsibilities.
Select Cancel to leave without submitting, or Reroute to confirm the selected destination.
Check Routing and the package status after success. The intended detail shows the original and current destinations and a Rerouted status.

The destination list depends on the receiving workspace's organization and approval-body setup. An option being listed does not guarantee that it is still valid when you submit.

If No destinations found appears, try a different team or responsibility. If Destinations could not be loaded appears, select Try again to reload the choices or Cancel to leave. Loading or searching choices does not itself change the package. A failure after selecting the final Reroute button needs the separate uncertain-result handling below.

Expected result: The new destination is recorded for the package. Its responsible people should check their access and available actions before proceeding. Existing participants may retain access; rerouting should not be used to remove access or recall shared information. Check the current destination and people separately.

Reject with a useful explanation¶

Select Reject on the package detail.
In Reject shared work, choose the closest available Reason. The design marks the reason as required.
Use Note to sender to explain the problem and what would help resolve it. Include enough context to be useful without adding unnecessary confidential information.
Select Cancel to leave without submitting, or Reject work to confirm.
Check for Rejected, the displayed explanation and any subsequent history.

Expected result: The exchange is marked rejected with its explanation. The sender can review the outcome through the shared-work information available to them. A replacement package, correction or further conversation requires a separate action.

The design includes readable wording such as Outside assigned responsibility and Wrong destination. The final set of reason choices and their mapping to supported decisions is still under review. Do not substitute a misleading reason merely to submit. Ask for help if none accurately describes the situation.

The confirmation's phrase “returns this package to the sender” describes the business handoff. It does not establish an automatic new transmission, deletion from the receiving workspace or a completed notification delivery.

Recover from an unavailable or uncertain decision¶

What happened	What to do
Choices could not be loaded before submission	Retry loading the choices. No decision has been submitted by that read.
Destination is no longer valid	Reopen the choices, check the current responsibility and select a valid destination.
A policy or connection rule prevents the action	Ask the workspace administrator to review the connection and permitted interaction. Repeated clicks do not change that rule.
The response times out or disappears after confirmation	Treat the outcome as uncertain. Read the package and history again before deciding whether anything needs to be retried.
A success message appears but the detail still shows the earlier state	Refresh the detail after allowing time for the workspace views to update. Seek support if the discrepancy persists.
The package has changed since you opened it	Review the current state and destination before taking another action. Do not rely on an earlier screenshot or open dialog.
Rejection is shown but Records still says to accept first	Do not assume a recovery action exists. The current design needs a clearer rejected-state explanation; ask the responsible owner what should happen next.

An old status or absent history entry does not conclusively prove that a submitted decision failed. Avoid repeatedly submitting different decisions to force the screen to change.

For support, provide the workspace, package title, action attempted, approximate time and visible response through an approved channel. Do not include the confidential package itself unless authorized. Support should investigate the recorded decision and the workspace views before recommending a repeat submission.

Understand the recorded decision¶

Acceptance, rerouting and rejection can each produce a separate activity-history entry for the receiving workspace. The package history, the current package status and the separate activity history are different views; they can arrive at different times and do not contain all the same details.

Recorded information	What it means
An acceptance entry	The exchange acceptance was recorded. It does not establish completion of the requested work, document approval or Records filing.
A rejection entry with a completed result	Recording the rejection succeeded. It does not mean the package was accepted or its requested work completed.
No entry for a blocked attempt	This decision recorder does not create the same success entry when a continuation rule prevents the action. Absence of that entry is not a complete account of attempted access or decisions.
The recorded time	Acceptance can use the completion time supplied with acceptance evidence; rerouting and rejection use the time the decision is applied. It need not be the time the history page received the entry.
A generic actor label	The recorder can use a generic label when a complete account profile is unavailable. The label alone does not establish who approved an assistant action.

The current fallback label is HiveAI approved action. It can also be used for an ordinary decision when the account information needed for a full actor snapshot is missing. Do not treat that wording as independent proof of assistant involvement or approval. Ask authorized support to reconcile the decision, account and any approval evidence before relying on the attribution.

The separate entry identifies the exchange but does not include a full list of affected people, the rejection explanation or the old and new routing values. Check the package's current detail and available history for that context. An empty affected-people list does not mean that nobody was affected, and a missing entry is not a reason to repeat the decision. See how activity history is recorded for snapshot and recovery limits.

For managers and administrators¶

For an approval-body destination, distinguish committee membership, chairperson and signing authority. The people are resolved from current authority; the choice does not itself cast a vote, sign a document or establish every recipient's action permissions.

Use acceptance as evidence that the exchange was accepted, rerouting as evidence of a destination change, and rejection as evidence of a recorded inability to proceed. None alone proves completion, document quality, a response-time target or delivery of a notification.

Coordinate responsibility when several people can act on the same package. Rerouting retains existing participation in the inspected implementation, so a destination change is not proof that the former recipients lost access. Workspace permissions and enterprise administration explain the broader access and connection context.

Continue with Open the primary document, Add people to shared work, package detail and history or the Shared work overview. Use Add shared work to Records for the separate filing action and uncertain-result recovery. The remaining exchange lifecycle is still being reconciled.