Understand history retention, exports and deletion¶
Activity history helps explain recorded actions, but it is not a permanent archive. Organization policy, scheduled retention and organization closure affect which entries remain available. This guide explains those effects for readers, administrators and decision-makers.
Draft scope: the rules below follow the inspected activity-history implementation. They do not certify a live environment or introduce new controls on the history screen. The platform export and closure guide owns the wider process, approval responsibilities, archive access and completion limits.
Why older history can disappear¶
The platform schedules retention work daily. Each run checks the organization's current history policy before removing eligible entries. The cutoff uses the run's recorded schedule time and the permitted number of retention days. An entry is eligible only when its action time is strictly earlier than that cutoff; an entry exactly at the cutoff remains for that run.
For example, a cutoff of 10:00 on 1 September removes an action recorded as occurring at 09:59 that day, while an action at exactly 10:00 remains for that run. This example explains the boundary; it does not establish your organization's retention period.
The comparison uses when the action occurred, not when you opened history or when its record arrived. An older action delivered late can therefore become eligible promptly. Daily scheduling does not promise removal at an exact instant: availability, policy checks, processing and failures affect completion.
A run works through eligible entries in batches. If it stops partway through, earlier completed batches can already be gone. An interrupted run is not proof that nothing changed. Support should establish the actual outcome before attempting recovery.
Increasing a retention period does not restore entries already removed. An empty view, or the earliest date currently offered in a filter, does not establish the configured policy or prove that every older action was captured.
What a legal hold changes¶
An active activity-history legal hold stops a retention run when that run checks policy. It also blocks this service's part of organization deletion. These are different outcomes: routine retention can finish as skipped, while organization deletion remains unresolved until the responsible team addresses the hold and recovery.
This hold applies to activity history. It does not, by itself, establish preservation of every document, work-item timeline, platform audit entry, backup or external-provider record.
Policy is checked when processing begins; the inspected code does not continuously recheck the hold between deletion batches. Changing a hold while work is already running is therefore not a verified immediate stop mechanism. Administrators should coordinate urgent changes with the responsible operator.
Removing a hold does not restore removed entries or prove that an earlier organization-deletion request has resumed. Support must verify the current job and the approved next action. Do not repeat organization closure simply to make a blocked status disappear.
What a history export contains¶
The activity-history contribution includes the organization's retained history rows, ordered by action time and entry identity. It carries recorded actor, action, outcome, related-work and timing information, plus recorded security context and metadata where present.
An organization export can contain information hidden from an ordinary history view, including recorded email, network or device details. Permission to read your own history is not permission to receive or share the organization's archive. Use the authorized archive process, verify the recipient and protect downloaded copies.
This contribution is activity history only. It is not a copy of the separate work-item timeline, discussions, the current employee directory, platform administrative audit or the contents of a linked document. Other services contribute their own declared data; check the archive against the business need.
The export contains what was retained when that contribution was read. It cannot recreate previously removed history or entries that never reached history. Services contribute independently, so the assembled archive is not evidence of one simultaneous capture across the whole platform. A later retry can produce a different contribution.
A contribution being collected does not mean the final archive is packaged, ready, downloaded or restorable. Follow the wider guide for readiness, access and expiry.
What organization deletion means for history¶
Organization deletion checks history policy again during processing. A valid positive retention setting is required, and an active legal hold blocks history deletion. When those checks permit it, this path removes the organization's governed history without an age cutoff. The ordinary retention period does not reserve recent history during organization closure.
The service reports the rows removed in that attempt. That result is one part of the wider deletion workflow. It does not certify removal from backups, earlier exports, separate histories, external systems or every other service.
Deletion and the later completion acknowledgement can fail at different points. History can already be removed while the overall job still needs investigation. A later attempt may find no rows because an earlier attempt removed them; a zero count alone is not evidence that the organization never had history.
Make the right decision from the result¶
| Situation | What to establish next |
|---|---|
| Older entries no longer appear | Check the selected view and filters, the actual retention policy and the processing outcome. |
| A hold was enabled | Confirm when it took effect and whether retention or deletion was already running. |
| Retention was skipped | Confirm the hold and policy; skipping does not prove organization deletion completed. |
| An export contains more detail than a history page | Check authorized recipient access and handle the archive as sensitive organization data. |
| Deletion is incomplete or its response is unclear | Ask support to read the existing job and participant results before requesting another action. |
| A service reports zero retained rows | Check the declared scope; do not treat it as proof that no copy exists anywhere. |
Administrators should establish the actual retention period, hold status, archive purpose and authorized recipient. See the workspace policy guide for current administration limits. Managers should identify the history needed for an investigation before it expires. Executives should ask for the scope, evidence date, completion state and remaining exclusions, rather than relying on a single success status.
Users should report a missing entry with the organization, work reference, approximate action time and filters used. Support should connect that report to the original business result, retained history and lifecycle processing. Use approved channels for protected information.
Connected recovery, policy-change timing, complete data coverage and initial reader acceptance remain open. How history is recorded explains capture and duplicate-delivery limits; reviewing history explains the intended reader journey.