Understand shared-work progress and evidence¶
A shared-work package has an exchange status and can also have records of acceptance, execution, review and completion. They answer different questions. The exchange status describes what happened to the exchange between workspaces; the recorded stages describe evidence about the work. Neither the file name nor the fact that work was sent proves that it was carried out.
Availability: Lifecycle recording and corrections exist in the service, but their connected user journey has not been verified. The intended detail and decision steps are explained in Read a shared-work package and Accept, reroute or reject. Step-by-step instructions for recording execution, review, completion and corrections still need verification. The inspected application remains a preview, and hosted use and reader acceptance remain unverified.
Distinguish the recorded stages¶
| Stage | What it records | What to check before relying on it |
|---|---|---|
| Acceptance | A decision to take on the work | Accepting the exchange and recording the receiving workspace's progress are separate actions. Acceptance alone does not mean work was performed. |
| Execution | Evidence about carrying out the work | Check its result and supporting reference. Recording an execution stage can include an unsuccessful outcome. |
| Review | An assessment of the work | Check whether the review accepted or rejected it, and whether that assessment was later corrected. A review label alone does not mean approval. |
| Completion | A recorded completion outcome after the required earlier stages | Check the actual outcome and any corrections. The stage label does not prove that every part of the platform has the same information or that an official record was filed. |
In the receiving workspace's lifecycle records, later stages require recorded acceptance, and review requires recorded execution. Completion requires the latest execution revision to have the expected successful result and the latest review revision to be accepted. A rejected review or failed execution must be resolved before that local completion path can succeed.
The platform records enterprise-exchange progress and receiving-workspace progress separately, updating the exchange first. If the receiving-workspace update fails, the exchange update may already have succeeded. Support must reconcile the two results before anyone treats an error as proof that no progress was recorded.
Read progress together with the outcome¶
The current progress summary shows the furthest stage that has a record: completion, then review, execution or acceptance. It is not simply the most recent entry by time. A later correction to acceptance does not move a completed package back to acceptance in that summary. Likewise, the existence of a completion-stage record does not, by itself, mean its outcome was successful.
The exchange can still display Accepted after execution, review or completion evidence is recorded. Later lifecycle records do not automatically change that exchange status to a new business outcome. The two labels are not interchangeable, and changing a frontend preview state does not update either record.
For example, a package may have an accepted exchange, recorded execution and a rejected review. It has reached review, but the work has not passed that review. A later correction may resolve the assessment while preserving the earlier evidence. Ask the responsible workspace to confirm the current outcome rather than judging it from the headline stage alone.
Responsibility and supporting information¶
The receiving-workspace recording path requires the actor to be a participant in the package. It does not establish a separate reviewer role or require that the reviewer be a different person from the person who performed the work. Organizations that need independent review must establish and verify that requirement explicitly; the presence of a Review stage is not proof of it.
A lifecycle entry includes a result, a supporting reference, a link to the work, start and completion times, and optional due-time and quality information. Required references and valid dates make the entry structurally complete; they do not independently prove the truth of the work or the contents of a referenced document. The current ordinary recording path does not accept an unverified message or meeting reference as authoritative communication proof.
Use the organization's agreed evidence and access practices. Keep the recorded dates, supporting reference and responsible person accurate, with enough context for an authorized reviewer to understand what was done and why it received that outcome.
Corrections preserve earlier evidence¶
A correction adds a new revision of the same stage rather than replacing its original entry. It must refer to the latest existing revision of that stage and include a correction type and reason. It cannot turn an execution record into a review record. Earlier evidence remains part of the history represented by this model.
The two services maintain their own lifecycle evidence identities. Their coordinated correction behavior still requires verification. If a correction is rejected as stale or cannot be matched, stop retrying it as a new event and ask support to reconcile the records. Do not assume that changing the explanation or starting a fresh submission will repair an earlier partial update.
When progress is missing or an update is uncertain¶
| What you observe | How to interpret and recover |
|---|---|
| Accepted exchange, with no later progress | Acceptance is not execution. Confirm whether the required work and evidence have actually been recorded. |
| Review exists but completion is unavailable | Check for a rejected review, unsuccessful execution, missing earlier stage or changed sharing policy. The responsible team should resolve the actual condition. |
| An update timed out or showed an error | Preserve the original attempt, intended stage and supporting reference. Ask support to check both the exchange and receiving-workspace records before another submission. |
| A stage or correction is reported as already recorded | Check the existing record and its latest revision. Do not start a different attempt solely to bypass that response. |
| Progress and history appear inconsistent | Refresh the read and compare the actual outcomes. The reader history is a summary, and the services can update separately. Escalate a persistent mismatch. |
| A correction was made but the headline stage did not move backwards | The progress summary retains the furthest recorded stage. Read the corrected outcome rather than inferring that the correction was ignored. |
When requesting help, provide the workspace, package title, intended stage, approximate time and visible error through an approved channel. Include the supporting reference only where the recipient is authorized to see it. A successful refresh or a notification is not a substitute for confirming the affected records.
Use progress responsibly in business reporting¶
One package can produce several stage records and later corrections. Counting those entries is not the same as counting distinct packages or completed work. A stage's date is supplied evidence about the event; it does not establish continuously measured effort, a contractual response-time commitment or an independent quality assessment.
The platform can publish contribution evidence about these stages for downstream reporting. Recorded due dates, quality bands, reviewers and outcomes need their business context. They do not automatically prove savings, productivity, compliance or individual performance. Review current outcomes and unresolved discrepancies before using the information for a business decision.
Continue with shared-work detail and history, sending and uncertain-send recovery, or the separate Records filing action. Shared-work updates and reporting explains notification, projection and source-reconciliation limits. Complete lifecycle UI verification, cross-service recovery, reporting acceptance and the initial reader review remain open.