What happens to temporary files and document-session data¶
An upload can stop being usable before its temporary bytes are physically removed. Background cleanup, the source item's retention rules and an organization-wide data request are different processes. Use this page to understand their effects without treating a status message as proof that every copy has been removed.
These are implemented background capabilities. This guide explains their current scope; it does not add a new user-facing cleanup, export or deletion screen. Connected recovery and organization-wide acceptance remain under review.
Expiry does not mean instant cleanup¶
Ordinary uploads normally begin with a 24-hour lifetime. Attaching a prepared file to a draft sets a 30-day retention window. Once the recovery service reports expiry, return to the source flow and check whether the work already succeeded before choosing the file again. An old upload row does not extend access.
Scheduled cleanup is triggered by an hourly platform event. It processes eligible expired uploads in the active workspaces returned by the platform, and retries uploads already queued for deletion. The event schedule is not a promise that physical removal finishes at a particular minute: tenant discovery, storage, persistence or later accounting can fail.
| File situation | Ordinary cleanup behavior | What it means for you |
|---|---|---|
| An unfinished or ready temporary upload expires | It becomes eligible for scheduled cleanup | Use the source's new-upload path after checking the earlier result |
| A draft attachment reaches its retention deadline | It becomes eligible for cleanup too | A draft is not a permanent file archive |
| Physical cleanup was queued | A later sweep can try again | Do not treat the file as available while waiting |
| A source operation has reserved the file | Ordinary expiry does not remove it | Reconcile the original operation through the source |
| The source has consumed the file | Ordinary temporary-upload expiry no longer controls it | Follow the source item's retention and deletion rules |
Keep the original file until the destination action is confirmed. The platform's storage allowance may not update at the same moment as the visible upload state; it depends on subsequent measurement and processing. Repeated uploads are not a way to force that reconciliation.
What this part of an organization export contains¶
The document-session service contributes a limited part of the platform's organization export:
- Records of selected work contributions, with summaries identifying which contributions were published.
- References to knowledge-library file versions that passed their upload checks, including their names, types and sizes, for the export service to process.
It does not place ordinary unfinished uploads, viewing sessions, all review/signing outcomes or every business document into this component's export. An in-progress knowledge upload is also excluded. The source services and the overall export process own other data and the final archive.
A reference identifies a knowledge file; it is not the file itself. Do not treat this component's row count as the number of business records, users, files or complete platform data items in an archive. Before relying on an export, confirm the overall job's scope and result through the organization data-request process.
Organization deletion is broader than ordinary expiry¶
An organization deletion request reaches this service through the platform's controlled lifecycle process. The service first attempts cleanup of its tracked upload storage, including the separately governed knowledge-document storage, and then deletes its local session, document-work and contribution-journal data.
This cleanup is broader than an ordinary expiry sweep: reservations and consumed upload rows are included in the tenant's tracked upload set. The source owners remain responsible for their business records and any independently managed copies. A failure partway through can leave some storage effects completed while other work remains outstanding.
A completion response from Document Session describes that service's local work. It is not a platform-wide deletion certificate, proof of removal from backups or a statement about copies previously downloaded by users. Use the overall deletion request's status and the applicable organization retention process to assess completion.
Recover an uncertain result¶
- Keep the original upload, source-item or organization-request reference and approximate time.
- For expired or inaccessible temporary files, return to the authorized source and inspect its saved result before uploading again.
- For queued cleanup or an allowance that has not refreshed, ask support to check the storage and accounting stages; avoid repeated discard or duplicate uploads.
- For export or deletion, follow the same organization request until the responsible team has reconciled all required service results. Do not start a replacement request merely to hide a failed or pending component.
Share visible errors and non-sensitive references with support. Keep temporary access links, credentials and document contents out of ordinary support messages. Operators have a separate internal reference for the exact cleanup, persistence and publication boundaries.
See upload recovery, file handoff, Records and the Shared work organization-data explanation for related source-specific limits. These guides describe different parts of the platform; none substitutes for checking the final organization-level outcome.