Shared work in organization data requests¶
An organization export or deletion is a platform administration process. It is different from sending a work package, removing a filter, rerouting work or filing it into Records. Follow the organization data-request guidance for authorization, the responsible recipient, archive expiry and confirmation.
Availability: Shared Work contributes to the inspected export and deletion processes, with the scope below. Complete archive coverage, deployed isolation and platform-wide completion remain unverified. This page does not describe a new export or delete button in Shared Work.
What the Shared Work export includes¶
The current contribution contains two kinds of reporting journal:
- Evidence recorded for acceptance, execution, review and completion, including revisions and references used by reporting.
- Saved daily reporting summaries and the inventories that identify their evidence entries.
These journals can contain work references, participant or actor information and recorded outcomes. They should be handled as organization data, even though they are not the ordinary Shared Work screen or its readable history.
The Shared Work contribution is not a complete export of the work packages. It does not include the full received and sent lists, package participation records or the separate lifecycle record tables. It also does not collect the primary files' contents. Other services can contribute their own data to the platform archive, but that does not establish that these omissions are filled. Agree the required scope with support and verify the actual archive before relying on it.
The reported export count is the number of rows in the included journals. It is not a count of work packages, attachments, distinct people or successful completions. Corrections and daily summaries can add rows without adding another package. Empty journals legitimately contribute zero rows.
The journals are read sequentially. The service does not establish one platform-wide capture at a single moment or a restore procedure. Concurrent activity, late reporting evidence and large exports require verification. Keep the source workspace and relevant period clear when comparing the archive with a screen or report.
What Shared Work deletion removes¶
The deletion scope is broader than the export scope. For the selected organization, this service's declared process removes:
- The two reporting journals included in export.
- Local acceptance, execution, review and completion records.
- Received and sent work-package records, with participation records dependent on received packages.
The service's rules select deletion rather than anonymization or a local retain option. That describes how this part of an authorized request is implemented; it does not replace the platform's approval and retention decisions. An ordinary work decision does not start organization-data deletion.
Deleting these local records does not, by itself, establish removal of the authoritative exchange held by another service, a counterparty workspace's records, filed Records entries, document contents, delivered notifications, backups or downstream reporting. Each relevant owner must be accounted for in the overall request. Do not infer that another organization's copy disappeared because the current organization's list is empty.
Removing source reporting journals also removes the material this service uses for exact evidence replay. Reporting recovery cannot reconstruct those deleted bytes from this journal. Any required preservation must be resolved through the authorized data-request process before deletion.
Understand completion and counts¶
Shared Work reports its own result to the platform job. That result is one service's contribution, not the final outcome of the entire organization request. Support must check the overall job and every required owner before confirming completion.
The deletion count comes from the service's declared delete operations. Participant removals happen through their parent relationship and are not counted separately by this service. The reported count therefore should not be read as the number of people, packages, files or all physical rows affected. This service reports zero anonymized rows; its current rules contain no retained-table option.
An error, timeout or missing completion message is not a safe basis for starting an unrelated second request. Preserve the original job context and ask support to reconcile its progress. Repeated processing may see different row counts after earlier work, while an export retried during ongoing activity may contain different data.
Questions to settle before relying on the result¶
| Your purpose | What support should confirm |
|---|---|
| Keep a usable copy of shared work | Which package fields, participation, lifecycle evidence and file contents are actually included across the archive's contributing services. The two journals alone are insufficient. |
| Compare reporting with an export | The same organization, time basis, activity and evidence revisions, including late arrivals or corrections. |
| Confirm organization closure | The overall deletion job, each service's outcome and the treatment of counterpart records, documents and downstream information. |
| Investigate a failed or partial request | The original job reference, failed stage, verified completed contributions and any remaining uncertainty. |
Share the archive and request details only through authorized channels. For ongoing work, use progress and evidence and background updates. Shared work and HiveAI explains assistant limits. Connected assistant and data-request acceptance, source refresh and the initial reader review remain open.