Two instruments: policies and labels
| Instrument | Granularity | Applied | Use for |
|---|---|---|---|
| Retention policy | Location-wide (a whole mailbox, site, Teams) | Automatically across the scope | Baseline "keep/delete everything here for N years" |
| Retention label | Item-level (a message, a document) | Manually, by default, by auto-apply (SIT/classifier/keyword), or as a container default | Precise handling of specific content; the on-ramp to records management |
Both do the same core job — retain, delete, or retain-then-delete for a period from a chosen trigger (created / modified / labelled / a custom event).
Scopes: static vs adaptive
- Static scopes name locations explicitly — simple, but they drift as the org changes and must be maintained by hand.
- Adaptive scopes are queries over users/sites/groups (by attribute — department, country, group membership). The scope re-evaluates automatically, so membership stays correct as people and sites come and go. Adaptive is the scalable default; static is the maintenance trap.
The principles of retention (how conflicts resolve)
When multiple retention controls touch one item, Purview resolves them by a fixed hierarchy — worth memorising, because it produces the surprises:
- Retention wins over deletion. If any control says retain, the item is kept even if another says delete. This is the "we deleted it but it's still discoverable" moment — the item survives (in the Recoverable Items / Preservation Hold area) until the longest retention expires.
- Longest retention wins.
- Explicit (label) beats implicit (policy).
- Shortest deletion wins — but only after all retention obligations are satisfied.
The practical consequence: a user "deleting" a file, or even a shorter deletion policy, does not override an active retention or an eDiscovery/legal hold. Data you think is gone is often preserved — that is by design, and it's the single most common retention misconception.
The delay pipeline (the other surprise)
Retention is not instantaneous. Applying or changing a policy propagates over a period (often up to seven days), and deletion at end-of-retention runs on a background cycle. Content also lingers in preservation areas after user-visible deletion. So "I set the policy, why isn't it applied / why is it still there?" is usually the pipeline, not a fault.
What to watch (proofs)
- The policy/label inventory:
Get-RetentionCompliancePolicyand its rules viaGet-RetentionComplianceRule;Get-ComplianceTagfor retention labels and their actions/periods — the full retain/delete map. - Scope type: which policies use adaptive scopes (
Get-AdaptiveScope) vs static — static scopes are the drift risk to flag. - Precedence in the wild: an item under both a retain policy and a delete action still present in Recoverable Items / Preservation Hold — "retention wins", proven, not asserted.
- Propagation status: policy distribution/enable state in the portal — before concluding a policy "isn't working", confirm it isn't just mid-pipeline.