Read a shared-work package¶
Open a package to understand what was shared, where it is directed, who has access and what has happened. Reading the detail does not accept the work or create an official record. Continue to Accept, reroute or reject shared work for decision confirmations and recovery.
Availability: This guide follows the current Awaiting review and Accepted Final Screens. The backend provides the detail and history reads described here. The inspected frontend remains a sample preview, including its displayed packages, status tabs and action buttons. A connected end-to-end journey has not yet been verified. Confirm which functions are available in your workspace before relying on them operationally.
Open and identify the work¶
- Find the package in Shared work, then select Open on its row.
- Check the title and whether the package is received or sent. Confirm the other workspace and the requested date; similar titles can refer to different exchanges.
- Read Work summary and requested interaction. The summary explains the request. The interaction describes what the sender wants, such as review or action; it does not establish that the action is complete.
- Check the primary-file name, type, size and version when shown. Read What changed in this version before comparing the package with an earlier copy.
- Read Routing, People with access, History and Records status before deciding what to do next.
- Use Back to shared work to return to the list. Returning or opening another package does not submit a decision.
Expected result: You can identify the package, explain the requested work, distinguish the destination from the people who can read it, and recognize whether further action is needed. If essential context is missing, refresh the read or ask for clarification before making a decision.
Understand the package context¶
| Information | What it tells you | What it does not establish |
|---|---|---|
| Received from / Sent to | The other workspace and direction of this exchange | That the signed-in reader personally sent it or has authority to decide its outcome |
| Shared by | The sender name recorded with the package, when supplied | A current staff-directory verification of that sender |
| Requested | When the work was requested | A response deadline |
| Updated | The most recent recorded exchange-state change | The time of every participant addition, file opening or other activity |
| Requested interaction | The kind of work requested by the sender | Permission to carry out every listed interaction, or evidence of completion |
| Formal exchange | The recorded formal-exchange designation, when supplied | A legal conclusion, signature or proof that an official Records item exists |
Ownership wording, such as Both workspaces keep a linked record, describes the exchange arrangement. It does not mean that selecting Open has filed the package into the receiving workspace's Records area. Check Records status separately.
Some details are optional. A missing size is not a zero-byte file, a missing version is not necessarily the first version, and absent change notes do not prove that a file is unchanged. A file summary may be unavailable while the rest of the package remains readable.
Separate routing from access¶
Routing describes the work's destination. When rerouting information is available, compare Current destination with Originally sent to. A destination can represent an organizational responsibility rather than one named person. Do not assume that everyone in the named department can see the package.
People with access describes the receiving package's recorded participants. An original recipient and an added collaborator have different roles in the journey. Being listed as a collaborator does not automatically make that person the recipient who can accept, reroute or reject the work.
The receiving participant list is not an enterprise-wide access report. Sent-work detail does not return that receiving participant list in the inspected read. An empty list on a sent package therefore does not prove that nobody can read it. File viewing and official-record access also have their own checks.
Workspace, capability and participant names may be loaded separately from the saved package. Staff names can reflect current directory information, while the sender name is saved with the exchange. If a name is missing or two destinations look indistinguishable, do not substitute a guess. Ask an authorized administrator or support person to verify the context.
Read status without overstating progress¶
The current awaiting-review design offers Accept work, Reroute and Reject to the intended decision-maker. The accepted design instead shows Add people and, when ready, Add to records. These examples illustrate different stages; they do not guarantee that every reader receives those actions.
Acceptance, performance of the work, review and completion are separate events. Accepted alone does not mean the work is complete. The system records evidence of these stages separately from the exchange status; a later recorded stage can coexist with an exchange status of Accepted. Do not infer progress by changing a status tab in the frontend preview. Understand shared-work progress and evidence explains stage prerequisites, actual outcomes, corrections and recovery when services disagree.
Use the actions returned for the current package and your account. Refresh after a state change before acting again. A visible action is a starting point for a separately checked operation, not a guarantee that a submission will still be allowed when it reaches the service. Read the decision guide and Add people guide for intended submissions and their current limits.
Follow the history¶
Read History from oldest to newest. The combined view can show when work was sent, allowed or applied exchange activity, additional participants and an official-record link when its saved details are complete.
For example, a history showing sent, rerouted and accepted explains how work reached its current state. A later participant entry explains when someone was added. Neither entry means that the underlying business work was completed unless completion evidence says so.
The reader history is a summary, not the complete operational audit:
- Denied attempts are not included in this reader view.
- The sent entry is constructed from the package's requested date and saved sender name.
- Additional-participant entries come from the receiving package's currently recorded participants. Original-recipient entries are not repeated as participant additions.
- Actor names may come from the current staff directory. Missing names can produce a general activity label.
- Detail, audit activity and names are loaded separately. They are not a single frozen snapshot, and entries with the same displayed time need not prove a causal order.
An empty history can also follow an unavailable detail read. It is not proof that the package never existed or that no action occurred. If a recent decision is missing, refresh and seek confirmation through the responsible workspace rather than submitting it again solely to make the history change.
Check the file and Records status¶
Open document starts a separate protected-viewing journey when the required file context is available. A file name alone does not establish that a viewing session can be created. The detail summary does not supply a direct download link, a checksum-verification result, a signature result or a retention decision.
Ready to add to records describes readiness checks, not completed filing. The current checks include received and accepted work, sufficiently complete primary-document information, permission to manage records and available record-registration choices. If a record is already linked, use the existing record when your access allows it.
If Records status is incomplete or inconsistent, ask support to verify the existing record before trying to file another. The Records guide explains the resulting official-record boundary. Use Open the primary document and Add shared work to Records for their intended steps and recovery limits.
Recover from incomplete or unavailable detail¶
| Situation | Next step |
|---|---|
| The row opens no package | Check the workspace and selected item, refresh the list and confirm participation with an authorized person. A missing detail does not distinguish deletion from lack of readable data. |
| A workspace, destination or person's name is blank | Retry the read. Preserve uncertainty and ask support to verify the context if the name remains unavailable. |
| The detail fails although the list loads | Retry later and record the message. Detail also depends on document context and, for some readers, Records setup; a list result does not guarantee all detail dependencies are available. |
| You can read the package but cannot make a decision | Check who is the addressed recipient and whether the work is still awaiting a decision. Reading access does not grant decision authority. |
| History differs from the title's Updated time | Compare the kind of event. Updated follows exchange-state changes, while the history can include participant or filing events. Refresh before reporting an inconsistency. |
| An action appears to have succeeded but the detail has not changed | Refresh and confirm the outcome with the responsible workspace. Do not repeat a decision or create another record merely because a read appears stale. |
| The preview shows comments, multiple attachments, a deadline or verified-download copy | Those examples do not establish support in the current detail and history reads. Confirm actual availability rather than treating them as live evidence. |
For support, provide the workspace, package title, approximate time, visible status and message, and which section failed. Use an approved channel for confidential contents. Managers reviewing progress should retain the same context and consult the responsible owner before turning these reads into performance or completion claims.
Continue with Open the primary document for the viewer, expiry and recovery, or Add people to shared work for colleague selection and access limits. Return to Shared work between workspaces for the business overview.