Bulk delete jobs in Dataverse
How Dataverse's bulk delete handles mass record cleanup — scheduling, filters, retention policies, and the operational discipline around storage management.
Dataverse storage is finite and meaningful — billed per GB above the licence-included allocation. Over time, environments accumulate audit logs, plug-in trace records, completed workflow logs, expired records, test data, old emails. Bulk delete is the platform's mechanism for systematic clean-up, configured as scheduled jobs that retire data based on filter criteria.
The model. A bulk delete job specifies:
- Target table — which Dataverse table to delete from.
- Filter (FetchXML) — which rows match.
- Schedule — run once or recurring (daily, weekly, monthly).
- Notification — email when complete.
When the job runs, the system:
- Identifies rows matching the filter.
- Deletes them in batches.
- Cascades according to relationship rules (related child records may delete too).
- Logs progress.
- Reports completion with row count.
Common use cases.
- Audit history retention. Audit records grow indefinitely without cleanup. A monthly bulk delete of audit older than 24 months keeps storage bounded while preserving meaningful history.
- Plug-in trace logs. Trace logs are diagnostic; they should be enabled for debugging and disabled or pruned aggressively otherwise. A weekly bulk delete of logs older than 30 days is common.
- Workflow log cleanup. Completed workflow / Power Automate run logs accumulate. Configurable retention based on success / failure status.
- Test data. Sandboxes accumulate test customers, opportunities, leads created during UAT. A "delete test records" job tagged by an attribute (e.g.
IsTestData = Yes) clears them. - Email retention. Tracked emails in CRM are storage-heavy. A bulk delete of completed emails older than a configurable period (1–3 years typical) controls storage growth.
- Activity cleanup. Old completed tasks, phone calls, appointments — historical but typically not actively used. Periodic cleanup.
- Closed cases with no activity. Closed cases over 5 years old (depending on retention policy) can be archived or deleted.
Cascade behaviour. Each Dataverse relationship has a delete-cascade rule:
- Cascade — deleting the parent cascades to children (e.g. delete the opportunity, all its activities go too).
- Restrict — refuses to delete if children exist.
- Remove link — deletes the parent, orphans children (sets the lookup to null).
- Cascade active only — cascades only to children in an active state.
Configure carefully; aggressive cascade can produce data loss surprises.
Performance. Bulk delete is system-friendly — runs in batches at a configurable rate to avoid swamping the platform. A million-row delete can take hours; that's by design. Plan jobs to run during quiet windows.
Soft delete vs hard delete. Dataverse doesn't have a built-in soft-delete pattern; deletes are hard. Some organisations configure a Deactivated status field and only "delete" by deactivating, with bulk-delete jobs later removing deactivated records after a retention period. This gives a recovery window.
Backup before delete. Major one-time deletes (initial cleanup of historical data) deserve a sandbox copy of production first — so the deleted data is recoverable if the criteria turn out wrong. Microsoft's point-in-time restore is 28 days; beyond that, no recovery.
Audit of bulk deletes. Each bulk-delete job execution records: when, by whom, what filter, how many rows. The audit trail is essential for compliance — auditors will ask what was deleted and when.
Limits.
- Permission required — bulk delete needs specific privileges, usually system admin.
- Some tables can't be bulk deleted — system tables, some configuration tables.
- API call quota — large bulk deletes consume API call budget on the tenant.
- Cascade depth — very deep cascades can run for a long time and consume substantial resources.
Compliance considerations.
- GDPR right to erasure — deletion may be obligatory for specific contacts on request.
- Statutory retention — some data must be kept for years (financial records, employee records). Don't delete prematurely.
- Legal hold — records under legal hold cannot be deleted. Mark and exclude from bulk deletes.
Operational discipline. Establish a tenant-wide retention policy. Configure bulk delete jobs aligned to the policy. Review monthly that they're running. Audit annually. Storage stays bounded; performance stays healthy.
Related guides
- Async jobs in DataverseHow Dataverse runs background work — system jobs, async plug-ins, workflow runs, and how to monitor, troubleshoot, and prevent the async backlog from getting out of hand.
- Cascading delete in DataverseHow Dataverse relationships behave on delete — cascade, restrict, remove link, and the implications for data integrity and accidental data loss.
- Business rules in DataverseHow business rules let you add field-level logic to forms without code — set value, lock field, show error, recommendation, and the limits of the engine.
- Business units and teams in Dataverse — a deep diveHow business units, owner teams, access teams, and Microsoft 365 group teams compose the security model in Dataverse — what each is for, how they interact, and the common design mistakes.
- Calculated and rollup columns in DataverseHow calculated columns and rollup columns work in Dataverse — what each does, the performance trade-offs, and when to use a formula column or a Power Automate flow instead.