# Turn the retention schedule into destination-specific work

Separate eligibility from execution and track each copy. A resumable workflow makes partial deletion visible instead of hiding it behind one database status.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Model the approved rule explicitly

Record the data category, policy version, trigger event and authorised exception state. Use the business event specified by the policy rather than defaulting every record to its creation timestamp.

Keep the schedule configurable through a controlled change process. A code constant with no owner makes later policy review difficult.

This synthetic task illustrates destination tracking. Its dates and states are examples, not a recommended retention period.

```json
{
  "actionId": "retention-example-36",
  "recordRef": "ticket-example-14",
  "policyVersion": "support-records-v2",
  "eligibilityCheckedAt": "2026-09-11T02:00:00Z",
  "holdState": "none",
  "destinations": {
    "primary": "complete",
    "search": "complete",
    "attachments": "retryRequired"
  }
}
```

## Select candidates without assuming execution is immediate

Use a bounded query to identify eligible records and create stable action identities. Recheck relevant state before destructive work so a new hold or corrected trigger is not ignored.

Make workers idempotent at each destination. A retry should recognise an already removed object or index entry as an appropriate outcome under the API contract, while still distinguishing an unexpected permission failure.

Avoid loading the entire eligible dataset into one long transaction. Use resumable batches and preserve the evidence needed to explain progress.

## Implement the actual destination semantics

For object storage, review version and lock behaviour and address the required object versions under policy. For search, remove the indexed representation and prevent the next ingestion run from restoring it from an obsolete source.

For exports or third-party systems, use the approved mechanism and record its confirmation or remaining limitation. Do not mark an unsupported destination complete merely because the main application can no longer display the record.

## Verify and report partial outcomes

Expose failed destinations with an owner and retry status. Keep metrics for eligible, completed, held and unresolved actions separate.

Minimise retained identifiers and content in the audit record according to its purpose. Finally, add the retention decision ledger or equivalent control to the restoration procedure so a recovered backup cannot silently republish data that should remain unavailable.

## Sources

- [AWS: object lifecycle management](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)
- [AWS: Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)