Deleting above retention: three approvals in Exchange, one in SharePoint

There is a line in the Priority Cleanup documentation you will hardly read anywhere else in the Microsoft 365 ecosystem: "items are permanently deleted and cannot be restored by users, by admins, or by Microsoft". Not the user, not the admin, not Microsoft. The feature has been in preview for SharePoint and OneDrive since mid-August, and general availability starts at the end of this month.

What makes that line stand out is the contrast with everything else. In Microsoft 365 almost any deletion has a way back: two-stage recycle bins, recoverable items, preservation hold libraries. We have written here about the Exchange recoverable items folder and its default window, which is exactly where most of the mail somebody thought was lost comes back from. Priority Cleanup is the first part of the product designed so that window does not exist.

We run customer Microsoft 365 tenants and we are the ones who answer for what can and cannot be recovered. So we read both Microsoft Learn pages carefully, the mailbox one and the files one, and what caught our attention is not the feature itself. It is that it is not governed the same way in both places.

Why Microsoft built it (and it is not what you would guess)

For mailboxes, the examples Microsoft gives are the ones you would expect: a privacy request about someone who has left the company, or data spillage — the email about a future acquisition sent to the wrong person — that has to go even with open eDiscovery holds.

For files, no. The literal title of the SharePoint and OneDrive page is "Override holds to clean up files for Copilot and reclaim storage". Override holds to tidy up what Copilot sees and get storage back. And the two use cases it lists are just as mundane: stale Teams meeting recordings and transcripts — "typically large and have little business value after 1-3 months", says Microsoft — and the OneDrive of someone who has left that cannot be deleted because files sit in the Preservation Hold library with unexpired retention.

The problem it solves is real, and that is worth saying before criticising anything. Microsoft 365 retention had no "this one, now": either you waited for the longest period to expire, or you lifted the hold with everything that drags along. Priority Cleanup is that button. Our objection is not that it exists. It is who gets handed it, and how many signatures it takes.

Three approvals in Exchange, one in SharePoint

It is the same button and the same engine — underneath, auto-applied retention labels — but the approval regime changes depending on where the data lives. Here is the comparison, built from the table both pages publish and from the text of their approver sections:

The line we find most important in that table is the third one, and it comes verbatim from the files documentation: "Separate approval from a retention admin isn't required to override retention settings". In the half of the tenant where most of a company's documents live, overriding a retention policy does not need a signature from whoever set it.

It is defensible, by the way, and we are not selling it as an oversight. The files use case is discarding last month's Teams recordings, and wiring three approvals into that — in a policy Microsoft describes as continual — would be unworkable. Our point is a different one: the control has stopped being technical and is now a list of names, and that list should be reviewed today, not on the day somebody uses it.

Who holds the role without having asked for it

The role you need is called Priority Cleanup Admin, and the documentation states how it is handed out: "This role is automatically added to the Organization Management role group but must be manually added to any other role group". Translated: if you have not touched anything, whoever sits in Organization Management already has it. In an SME tenant that usually means the whole systems team, plus a consultant who came in on a Tuesday two years ago.

And there is a detail of the two-person rule worth reading slowly. On the mailbox page, about the first approver: "This should be a different person to the user who created the priority cleanup policy, but isn't enforced". It should be someone else, but the product does not enforce it. On files it is enforced, and more elegantly: "The last person to edit the policy can't also turn it on". Two different criteria for the same principle, inside the same product and the same configuration screen.

That said, and to avoid leaving the wrong impression: Exchange needs three different roles — priority cleanup admin, retention manager and eDiscovery admin — so if there are three actual people behind them, the control is considerably stronger than on files even with the two-person rule unenforced. The risk is not symmetric, and one answer for both sides will not do.

What does stop it

The switch is a before decision, not an after one

The feature can be switched off tenant-wide, under Purview > Data Lifecycle Management > Priority cleanup settings, and it is a single switch: it turns off mailboxes and files together. Microsoft itself suggests this for a particular kind of organisation, and the sentence is worth quoting in full: "highly regulated organizations that use Preservation Lock might want the additional safeguard of turning off priority cleanup at the tenant level".

Now the part to read twice. If you switch the control off with policies already created, the documentation is explicit: "Existing priority cleanup policies continue to function". They can be deleted, yes, but they cannot be modified and they keep running. And there is one more turn: "Although you can delete a priority cleanup policy, if the approval process for it is complete, items might still be permanently deleted". Deleting the policy after the approvals are in does not necessarily stop the deletion.

It is a before switch. Same as auditing, which per Microsoft must be on at least one day before the first policy is created and run, and which is also required to view simulation results. The documentation does not say what happens if it is not: we would not turn anything on without checking first.

And when you go looking for that trail, the events do not appear in the portal dropdown — "these events don't have friendly names to select from the Microsoft Purview portal" — so you have to type them out:

PriorityCleanupTagApplied     # the item enters the workflow
PriorityCleanupDelete         # a mailbox item is deleted
PriorityCleanupFileRecycled   # a SharePoint or OneDrive file is deleted

Where our sources do not agree

We would rather say it than paper over it. The Microsoft Learn page states that "the feature itself is enabled by default at the tenant level". Message centre post MC1261587 — published 25 March 2026 and updated on 19 August — says the opposite: that the capability "is not enabled by default and requires explicit admin configuration".

Our reading, and it is a reading rather than a fact: both sentences hold at once if "enabled" refers to the switch and "not enabled by default" to the effect. The control ships on, but nothing is deleted until somebody creates a policy, turns it on and somebody else signs. The message centre post says as much: "There is no change to user workflows unless an admin configures and applies a priority cleanup policy". If your reading differs, checking takes thirty seconds in your own tenant portal, and that one beats ours.

There is a second gap, and we leave that open too. The message centre post announces a "Delete data permanently" option for files whose effect is that the content is no longer discoverable in SharePoint search, in Copilot or in eDiscovery. The Learn page we read describes the second-stage recycle bin path. We could not find that new option described on Learn, so we do not state how it behaves. We will look again when the documentation catches up.

And your backup — does it save you here?

This is the fourth time this summer that this blog lands in the same place, and we will say so out loud before saying it again: a retention policy is not a backup, the backup Microsoft sells never leaves Microsoft, and archiving is not copying either. Priority Cleanup adds a case neither of those covered: a legitimate deletion, approved and audited, carried out from inside by people with permission. It is not ransomware and it is not a platform failure. It is a correct procedure run with a badly written KeyQL query, or with a scope wider than intended.

A backup outside the tenant gives you the file back only if two conditions hold. That it was copied before the deletion, which is obvious. And that your backup's own retention does not purge what disappears from the source, which is not obvious at all. There are Microsoft 365 backup products that mirror deletions: if the item leaves the source, it leaves the copy once a short window expires. That clause decides whether you have a backup or a mirror, and it is the question we always ask when we set up Microsoft 365 backup for somebody.

Five things we would do this week

A new entry in the inventory

There is no bug here. Priority Cleanup does exactly what its documentation says, solves a problem that existed, and ships with more safeguards than a Microsoft 365 deletion usually gets. What changes is something else: the list of who can make a piece of your company's data disappear has one more entry as of this month in SharePoint and OneDrive, and that entry needs a single signature.

Failure is inevitable; an outage is a design decision. This time there is not even a failure: there is a new capability and a pending decision about who holds it. We review this as part of our Microsoft 365 and compliance and continuity work, along with the question behind it that almost nobody asks in time: if it disappears tomorrow, where does it come back from?

Sources (verified on 3 September 2026): the irreversible-deletion sentence, three always-required approvals, approver roles, the unenforced two-person rule, the records and review-set exceptions, the Preservation Lock note, behaviour when the switch is turned off, the auditing requirement and the log events — Microsoft Learn, "Use priority cleanup to expedite the permanent deletion of sensitive information from mailboxes". The files page title, the Teams and Preservation Hold library use cases, single approval, mandatory simulation, second-stage recycle bin and the last-editor rule — Microsoft Learn, "Override holds to clean up files for Copilot and reclaim storage". Preview and general availability dates, the "Delete data permanently" option and the activation sentence — Microsoft 365 message centre post MC1261587, published 25 Mar 2026 and updated 19 Aug 2026 (visible from inside the tenant). The mailbox Learn page is marked as a preview feature and subject to change; the SharePoint and OneDrive page carries no such note.