Bulk delete and data lifecycle

What it does

Bulk deletion runs a saved query as a background job that removes matching rows, optionally on a recurrence, with email notification when it finishes. It's the blunt end of a data lifecycle that runs active → inactive → deleted, with long-term retention sitting in the middle.

Key facts

Jobs are created from the Bulk Deletion Wizard under Settings > Data management > Bulk deletion in the admin centre, and need System Administrator.
A single job can span multiple tables, run on a schedule, and start at a chosen time.
The wizard has a Permanent deletion checkbox. Tick it and rows skip the move into the deleted-records tables entirely — faster, and unrecoverable.
If deleted record keeping is turned on for the environment, rows deleted by a bulk delete job can be restored, either the whole job or individual records, from the job's Deleted Records tab.
Bulk deletion jobs are now solution-aware. Add them via Add existing > More > Other > Data Life Cycle Config, the same component type that carries retention policies.
Only job definitions travel in a solution, not data — and an imported bulk deletion job runs immediately on import.
Only admins can create or import solutions containing bulk deletion jobs, and only jobs created in Power Platform environments can be solution-aware.
A Run details tab on each job shows status, start and end time, records deleted, records failed and the errors. A status of Failed means the job never started.
Audit log deletion runs as the same kind of background job and appears in the same Bulk deletion view. Audit deletion processes at roughly 100 million records a day.
Long-term retention is the alternative to deletion for data you must keep: it moves rows into the Dataverse retention store where they're read-only and can never come back to the live state.

When to use / skip

Bulk delete is right for data that's genuinely worthless — failed imports, sample data, expired test rows, closed activities past their usefulness. It is the wrong tool for anything with a compliance angle, and reaching for it because storage is full is how clients delete things they were legally obliged to keep. Design the lifecycle first: decide per table whether the end state is retention or deletion, write it down, then build the jobs. And be honest that most organisations have no lifecycle policy at all, so this conversation starts with the business, not the admin centre.

Configuration decisions

Per table: does old data get retained long term, bulk deleted, or left alone — and what's the age threshold.
Whether jobs use permanent deletion for speed or go through deleted-record keeping so mistakes are recoverable.
Whether lifecycle jobs are managed as solution components through dev/test/production, or configured directly in each environment.
Recurrence and start time, chosen so jobs don't collide with integrations, overnight batches or the audit deletion jobs.
Who receives the completion notifications and what they're expected to do with a non-zero failure count.

Gotchas

Importing a solution containing a bulk deletion job fires the job on import. Import it into production during business hours and you'll find out what it targets the hard way.
Permanent deletion plus a slightly wrong FetchXML filter is genuinely unrecoverable short of restoring the whole environment into a new one.
Deleting the parent of a Cascade All relationship in bulk takes the children with it, and the row count in the job tells you nothing about how far the cascade reached.
Cascade delete rules and plug-ins registered on Delete all fire during a bulk delete job, so a job that looks like it removes 50,000 rows can generate far more work than that.
Retention policies also run existing delete cascades and plug-ins, and the retain action itself can be extended with custom plug-ins — so a retention run isn't quiet either.

Consultant notes

Always run a new job in a sandbox with production-shaped data first, and check the count before you check the box.
Make the lifecycle policy a signed deliverable naming a business owner per table. Without one, storage cleanup becomes an IT decision about business records, which is exactly the wrong way round.
Solution-aware jobs are a real improvement for ALM, but explain the immediate-run behaviour to whoever manages the deployment pipeline before they schedule an import.
Where the client is deleting to reclaim space, check whether long-term retention would do the job instead — retained data compresses and stays queryable, deleted data doesn't come back.

Revisit if deleted record keeping changes scope, or once bulk delete gains more of the retention policy's tooling.