Skip to main content
Legal holds and mandatory retention preserve covered assets and records against supported destructive operations. Use them when you need to keep a workspace’s contents or one asset while a matter or retention requirement remains active.
A workspace owner places a hold, which is audited. A destructive operation goes to the hold check and is either allowed when no hold is active or refused.

A destructive operation asks the hold check first. A held or unanswered check refuses it.

​
Choose the scope and kind

A hold on one asset also prevents a purge that would destroy the whole workspace containing it. Folders, projects, and collections cannot receive an asset hold because a hold on those containers does not extend to their contents. Reaching a mandatory retention date permits release. It does not release the hold automatically.

​
Who can place and release holds

You must be a signed-in person with a live owner membership in the target workspace. Administrator status alone does not grant this authority. By default, API keys are refused, including an owner’s API key. A deployment’s decision-authority policy can admit an owner’s key for these decisions; ask Athena support how yours is set. Agent and Automation credentials, impersonation and view-as access cannot place or release holds. Athena has no screen for managing holds yet. A workspace owner places and releases holds through Athena’s administrative API, which is not part of the public API reference or the SDKs. Contact Athena support for the procedure.

​
Arrange a hold

  1. Identify the workspace and decide whether the hold covers the whole workspace or one asset.
  2. Choose a legal hold or mandatory retention and record the reason.
  3. For mandatory retention, choose the release-not-before time and its time zone.
  4. Contact Athena support for the administrative API procedure, then act as the signed-in workspace owner.
  5. Read back the recorded hold and the enforcement state before relying on it.
Placement and release each record an audit event with the decision. The hold and release records retain their reasons. The administration audit event contains identifiers rather than the reason’s content.

​
Read back enforcement

After a hold is placed, the owner can list the workspace’s holds, including released ones, and read back how deletion is answered for the target. The readback shows hold identifiers and reason codes. It does not show the hold’s reason text. Some destructive operations, such as a workspace purge, depend on a deployment setting. Ask Athena support to confirm the readback for your deployment before you rely on a hold.

​
Understand the limits

Covered retention jobs preserve records such as conversation checkpoints, database query history, and Computer restore points. A cross-workspace asset move also checks holds and is refused unless its checks allow it. Archiving is a reversible operation and does not ask the hold check. A hold is not a general freeze on editing. A hold on a database asset does not intercept SQL writes or deletes of individual rows inside the database. Arrange any application-level record preservation separately.

​
Release a hold

  1. Confirm that release is appropriate and that any mandatory retention date has passed.
  2. Use the administrative API procedure as a signed-in workspace owner and provide a release reason.
  3. List the holds with released entries included to verify the release record.
Release is recorded permanently. A released hold cannot be released again.