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.

Updated 2026-11-30

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:

  1. Identifies rows matching the filter.
  2. Deletes them in batches.
  3. Cascades according to relationship rules (related child records may delete too).
  4. Logs progress.
  5. 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