Retention and the Preservation Hold Library

What retention does

Retention (authored in Microsoft Purview as retention policies applied to locations, or retention labels applied to items) enforces two independent promises: retain content for at least N (you can't lose it early) and/or delete it after N (you can't keep it forever). The two combine — retain then delete is the common records shape.

The Preservation Hold Library (the mechanism)

Here's the part that surprises everyone. When a site is subject to retention, each document library gains a hidden partner: the Preservation Hold Library (PHL). The rule:

• Edit or delete a file that's under retention, and a copy is written to the PHL before the change/deletion is honoured at the visible layer. The user sees the file edited or gone; a preserved copy lives on in the PHL.
• A timer job (runs roughly every few days) sweeps the PHL: copies whose retention period has fully elapsed are purged; copies still within their period stay.

This is copy-on-write for compliance. It means retention never depends on users behaving — deleting doesn't defeat it.

Deletion timing (why it lags)

Because of the PHL, "I deleted it" and "it's actually gone" are far apart:

• A deleted file goes to the recycle bin (versioning-recycle concept) for its window, AND a preserved copy sits in the PHL until its retention clock expires and the timer job collects it.
• So genuine purge can be weeks to years after the user's delete, depending on the retention period — entirely by design.

Adaptive vs static scopes

Retention policies apply to locations via static scopes (named sites/OneDrives) or adaptive scopes (a query — e.g. all sites with a given property — that re-evaluates membership automatically). Adaptive scopes are the maintainable choice at scale; static lists drift as sites are created.

The failure modes

• "I deleted things but storage didn't drop." The PHL still holds copies — expected until the retention period elapses (storage-model concept). You cannot delete your way under quota past a retention obligation.
• The PHL is hidden but real — it consumes the site's storage quota and shows in eDiscovery. Admins hunting "why is this site so big" miss it because it's not a normal library.
• Deleting a site under retention is blocked/deferred — the obligation outlives the container.
• Label vs policy precedence — an explicit retention label can override a broader policy; the principle across conflicts is that the most retentive outcome wins (retain beats delete).

What to watch (proofs)

• Retention applied to a location: Purview → Data lifecycle management → policies, and per-item Get-PnPListItem label properties — what's actually in scope.
• The PHL's presence and size: the site's storage metrics vs visible content — the gap is largely PHL + recycle bin; it's why post-cleanup storage lags.
• Timer-job effect over time: PHL volume trending down as periods expire — proof purge is happening, just slowly.
• Hold interaction: Get-SPOSite <url> under an eDiscovery hold — content is preserved regardless of retention policy (ediscovery concept).