Skip to main content

Asset Retention and Disposition

Daniel Tan
Updated

Asset Retention & Disposition – End User Guide

This guide explains how Asset Manager automatically controls the end‑of‑life of assets using retention metadata and chained archive + purge policies. It describes what information is stored on each asset (policy days, execution dates, status, violations), how scheduled checks ensure assets are not in active use before disposition, and how automated archive to S3 Deep Glacier and timed purge work together. It also outlines what you see in the UI, how to interpret statuses and violations, and what actions you may need to take when retention needs to be adjusted or when disposition is postponed or fails.

1. What is Retention & Disposition?

Retention is metadata attached to each asset that defines how long it stays online and what happens next. Disposition is the action taken when retention expires: Archive (move to cheap cold storage) or Purge (permanently delete).

An asset can have an archive policy, a purge policy, or both chained together (archive first → purge later).

2. Retention Metadata — What's Stored on Each Asset

When an OM system task (e.g. Asset Retention Schedule – Archive + Purge) runs, it writes a retention block onto each asset. The metadata fields are:

The unique key for each retention entry is AM ID + Type. If the same task fires again for the same asset, values are overwritten, not duplicated.

Version: The OM task has a "Version" field where you choose All (applies retention to every version of the asset) or Current (applies only to the active version in the task). See ‘Workflow’ section for more details.

3. Workflow

The below shows the flow from embedding retention metadata to asset disposition.

OM System Task (Asset Retention Schedule) → AM Add Retention Metadata to Asset → Retention Expires → AM execute the Asset Disposition

To add a retention for an asset, use one of the following OM system tasks

Shared Services -> System Tasks -> services -> Asset Retention Schedule – Archive + Purge 

Shared Services -> System Tasks -> services -> Asset Retention Schedule – Purge 

Retention is determined by time in days.

All asset types are supported for retention metadata. However, NOT all asset types are supported to archive to AWS.

3.1 Asset Retention Schedule – Purge

Below are the task workflow fields.

  • Fill in the 'Purge Policy (Days)

    • Days are counted from the day when the task is executed.

  • Fill in ‘Storages’ - ‘All’, ‘On-Prem Storages Only’ or ‘S3 storage Only’.

    • Not supported: Option for individual storage.

  • Fill in “OM Versions” - ‘Current’ or ‘All’.

    • ‘Current’ means the selected OM asset version. It does NOT always mean the latest.

    • Not supported: Selective OM asset version

 
 

3.2 Asset Retention Schedule – Archive + Purge

Below are the task workflow fields.

  • Fill in the 'Archive Policy (Days)

    • Days are counted from the day when the task is executed.

  • Fill in the 'Purge Policy (Days after archive completion)

    • Days are counted from the day when the archive has completed.

  • Fill in ‘Storages’ - ‘All’, ‘On-Prem Storages Only’ or ‘S3 storage Only’.

    • Not supported: Option for individual storage.

  • Fill in “OM Versions (Archive)” AND “OM Versions (Purge)” - ‘Current’ or ‘All’

    • ‘Current’ means the selected OM asset version. It does NOT always mean the latest.

    • Not supported: Selective OM asset version

    • Below shows the task configuration and the grid table shows the possible combination of values for 'OM Versions”

       

 

 

4. What You See in the UI

Retention Tab

After the OM system executed, then on the asset’s MAM attributes (in OM) or asset details (in AM) there is a Retention & Disposition tab shows a table with columns:



 

Click any row to expand a detail view showing: Comment, Updated By/At, Policy Violation, RescheduledCount, and full history.

Violation messages are structured for readability — for example, active-task violations show the Task IDs (no Job IDs) and include a clickable link to the OM Asset page so you can investigate usage directly.


Search & Filters

Assets with retention (any status) are searchable via AM's filter/search in AM.


5. How Automated Disposition Works

5.1 Dependency Check (Pre-Disposition)

Before any disposition action fires, a scheduler service multiple times a day at an hourly rate. For each asset with a pending retention whose DueDateTime has passed, AM queries OM to check whether the asset is still being used in any task with a status other than Complete.

  • If dependencies are clear → the asset is marked ready for disposition.

  • If dependencies are NOT clear (asset still used in active tasks) → disposition is postponed by 2 weeks. The DueDateTime is bumped, RescheduledCount increments by 1, and a violation message is added:

    "OM Asset with ID {id} & Version {versionId} is currently in use by {n} active OM Task(s): {taskIds}. See Asset here for Usage."

  • If AM can't reach OM → an error message is added to the retention comment, but the status is not changed.

Policy violations kick in if rescheduling exceeds limits:

  • RescheduledCount > 5 → status set to Expired, violation = ExceededRetentionLimits.

  • Duration > 180 days → status set to Failed, violation = ExceededRetentionLimits, comment = "Duration of retention exceeds 180 days."

5.2 Automated Purge Execution

A scheduled task runs once a day, finds all assets whose purge retention has expired, and purges up to 50 assets per cycle (remainder rolls into the next hour).

Key purge rules:

  • Applies to all asset types and all storage including S3 — except Deep Glacier. If at least one S3 location in any region is in Deep Archive, no purge occurs.

  • "Deep Blob" asset is not supported. A “Deep Blob” is an asset that was ingested as a ‘blob’ and have more than 3 levels of nested folders.

  • Each purge error does not block other assets — errors are isolated per asset.

  • On success: retention status → Completed, timestamp updated. The asset no longer appears in disposition search results.

  • On failure (automated run): status → Failed, error comment added. Retention failure is only recorded when the action is triggered by AM's scheduler, not by manual user action.

  • If the asset is located only in S3 and is STILL eligible for purge if it’s in Deep Glacier: status → Success. Note: User cannot purge from Deep Glacier, only AM can purge via API.

  • If the asset is already purged: no error — status quietly set to Completed with a comment noting the purge and the user.

  • If the asset is orphaned: purge still executes; orphaned status is removed from the record.

  • If no eligible assets exist to purge for that retention entry: status → Completed (nothing to do).

  • Retention status is marked Completed only if all applicable storages under the retention (ALL/S3/on-prem) were purged. If one or more storages still have checked-in copies, the status remains in the previous either Pending or Expired.

5.3 Automated Archive Execution

A cron job runs at the end of each day (~11:59 PM PST). It finds all assets whose archive retention expires that day and triggers archive to AWS S3 Deep Glacier (US-East-1 region only).

Key archive rules:

  • Only for asset types AM supports for AWS archive. Unsupported types are skipped silently.

  • If archive is already in progress (user triggered it manually), the scheduler does nothing — no duplicate.

  • On completion: archive retention status → Completed, timestamps updated.

  • On failure: status → Failed, details in comments.

5.4 Combined Archive + Purge Flow

When both policies are registered together, they chain:

  1. Registration: The OM system task writes both an Archive Policy (days) and a Purge Policy (days). Both appear in the retention metadata with their own status, execution date, and detail view.

  2. Execution date calculation for purge:

    Purge Execution Date = System Task Execute Date + Archive Policy (days) + Purge Policy (days)

    Example: Task runs 02/17/2026 10 PM PST, Archive = 15 days, Purge = 30 days → Purge executes 04/03/2026 10 PM PST.

  3. Archive expires first → AM executes archive. On completion, purge execution date is recalculated to now + Purge Policy (days).

  4. If archive fails and purge comes due → AM does not purge. Instead it reschedules purge to Original Execution Date + Purge Policy (days), increments RescheduledCount, and adds a comment explaining why.

  5. When purge expires, AM checks for an archive entry:

    • Archive completed → execute purge, set purge to Completed.

    • Archive not completed → postpone purge (new date = old date + Purge Policy days), add comment.

    • No archive entry at all (legacy) → fallback to default 14-day postponement.

  6. If archive is postponed (rescheduled), purge is also pushed forward by the same delta to maintain the gap.

  7. If user purges from all locations before archive runs → archive status set to Failed (nothing left to archive).

  8. Overwrite rules: Both archive and purge metadata can be overwritten by a subsequent OM task (archive-only or archive+purge). Any archive metadata update automatically adjusts the purge retention and execution date.

6. Tips, Troubleshooting and Questions

To check retention on an asset

Open the asset → go to the Retention tab → review the Policy (Days), Execution Date, Status, and any Violation or Comment entries.

Requesting policy changes

If you need to extend or shorten a retention window (e.g. extend from 365 → 730 days), re-run the OM system task, which overwrites the existing retention metadata and recalculates execution dates.

Acting on violations

If you see a Failed or Expired status with a violation reason like ExceededRetentionLimits, investigate the root cause (e.g. tasks that won't complete) and resolve the blocker so the next scheduled run can proceed. Escalate issue to GTS if you cannot resolve.

Watching for edge cases

  • Asset purged before archive ran → archive will show Failed. This is expected.

  • Purge date somehow set before archive date → AM will automatically postpone the purge until archive completes, and add a comment explaining the delay.

  • Repeated reschedules → Not implemented yet, and it should not be in expired as expired is a good state (need to discuss). → after 5 reschedules, the status flips to Expired with ExceededRetentionLimits. Escalate to resolve the blocking dependency.

 

Comments

0 comments

Article is closed for comments.