Understand shared-work updates and reporting¶
Sending work, updating its exchange status, making it visible to a colleague and including its evidence in a report involve different parts of the platform. Those views can update at different times. A notification means there is work to examine; it does not prove that the work was accepted, completed or filed into Records.
Availability: This guide explains the inspected background behavior and its limits. The connected delivery, recovery and reporting journeys remain unverified. Use the sending, decision, people and progress guides for their intended actions and specific recovery advice. The inspected frontend remains a preview.
How an exchange becomes visible¶
After dispatch, the platform processes information about the exchange to create a received item in the destination workspace and a sent item in the originating workspace. Both refer to the same exchange. These are workspace views of the package; they are not two independent submissions or proof that two official records exist.
The receiving view also resolves the people currently addressed by the routing destination and adds their participation. This affects who can find the received package. A person's absence from the Received list can therefore reflect participation or a delayed update, rather than deletion of the exchange.
Later status updates change the saved exchange status and routing information. They do not themselves record execution, review or completion evidence. An update that arrives before the package is available can be missed, and a delayed older update can replace a newer displayed status. Support must compare and resolve a persistent discrepancy; refreshing the page alone cannot repair the underlying update order.
Repeated delivery of the original package information does not create another item where that exchange is already present. It can update the primary-file information and resolve addressed people again, but it does not comprehensively replace the existing package's title, routing and status. Support should establish which update is missing before choosing a recovery action.
What notifications and rerouting mean¶
A new addressed participant can receive an inbox notification about the shared work. The notification is prepared for restricted, summary-only presentation. Its existence does not prove that the recipient opened the package, read its document or took a decision. Actual notification delivery and the link into the application still require connected verification.
Rerouting can add the people addressed by the new destination. The inspected update does not automatically remove earlier participants. Do not assume that a previous recipient loses access merely because the package now names another destination. Confirm participation and the organization's access requirements through an authorized administrator.
The same person can already participate for another reason. Reprocessing does not necessarily change that person's recorded participation category or send another availability notification. An absent second notification is not proof that the routing update failed.
When workspace collaboration is suspended¶
Changes to a workspace's collaboration entitlement can prevent new sends while existing received work remains available through its normal read rules. Suspension does not itself delete those packages or prove that every later action is allowed. Individual actions can have their own current-policy and authority checks.
The application's suspension information can become outdated. Missing information is not confirmation that collaboration has been restored. If an administrator and the application disagree about availability, ask support to verify the workspace's current entitlement and whether the application has received the change. Do not resubmit a package simply to test whether a suspension has cleared.
How progress reaches reporting¶
Acceptance, execution, review and completion can each produce evidence for downstream reporting. Corrections add revisions. One package can therefore have several evidence entries; their count is not the number of distinct packages, successful outcomes or people who independently reviewed the work.
The platform retains a source copy of published evidence so it can identify and resend exact missing entries. Matching evidence already recorded at the source is not automatically published again as a new entry. Reconciliation is a controlled support operation, not a reason for a user to repeat the original work action.
Evidence is grouped by its recorded event day in UTC. Local calendar dates can differ, and the event's recorded completion time can differ from when its evidence becomes available to reporting. Compare the same workspace, time basis, activity and revision before treating two totals as contradictory.
A day's source summary describes the evidence found for that group at reconciliation time. An empty group can have a valid zero-entry summary. Neither an empty nor a nonempty summary proves that every expected business action has happened or that all other services have completed their processing.
Late evidence and corrections need care. If a day's evidence changes after its summary was established, the inspected recovery path can reject a mismatch rather than silently substitute different contents. This protects the identity of the recorded evidence, but it does not establish an automatic way to settle every late arrival. Support must reconcile the affected source and report before claiming the day is complete.
Recover from a delayed or inconsistent view¶
| What you observe | What to do |
|---|---|
| The send appeared successful but the package is missing | Confirm the workspace, direction and filters. Preserve the original attempt and ask support to check dispatch and the workspace views before sending again. |
| A colleague received a notification but cannot find the package | Check their workspace and recorded participation. Report the notification time and visible failure; the notification does not grant access by itself. |
| The status appears to return to an earlier value | Refresh once to rule out a stale page, then escalate a persistent mismatch. Support should compare the exchange with the delivered workspace updates. |
| Rerouting changed the destination but the former recipient still sees the package | Earlier participation is retained by the inspected update. Ask the authorized administrator to assess access; do not treat rerouting as removal. |
| An administrator restored collaboration but sending is still unavailable | Check the current entitlement and its propagation with support. Preserve the error and avoid repeated new submissions. |
| A report is missing progress or shows a different total | Identify the workspace, UTC/local date basis, stage, outcome and correction revision. Reconcile the existing evidence instead of recording the action again to increase the count. |
Use an approved support channel. Provide the package title, affected workspace, approximate time, the view or report, and the visible discrepancy. Include confidential evidence only when the recipient is authorized. Keep the original submission context available so support can distinguish a delayed read from an uncertain mutation.
Business interpretation¶
Read progress and evidence alongside reporting. The furthest recorded stage, its actual outcome, its corrections and the exchange status answer different questions. A delivered notification is not a read receipt; an accepted exchange is not completed work; a source reconciliation summary is not an independent assessment of productivity or compliance.
Connected delivery and recovery tests, downstream report interpretation, cross-workspace access and the initial reader review remain open. Shared work in organization data requests explains the limited export and broader deletion scope. Shared work and HiveAI explains bounded answers, proposed changes, uncertain outcomes and protected-file limits; connected assistant acceptance remains open.