Bulk delete jobs in Dataverse
By Emil Björk · Microsoft business apps consultant, Gothenburg
How Dataverse's bulk delete handles mass record cleanup — scheduling, filters, retention policies, and the operational discipline around storage management.
On this page (7)
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. It runs as one type of async job among several the platform manages in the background — the same asynchronous execution service that also runs async plug-ins and workflow instances.
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
- Cascading delete in DataverseHow Dataverse relationships behave on delete — cascade, restrict, remove link, and the implications for data integrity and accidental data loss.
- Async jobs in DataverseHow Dataverse runs background work — system jobs, async plug-ins, workflow runs, and how to monitor, troubleshoot.
- What is Microsoft Dataverse?Microsoft Dataverse is the relational data platform underneath Dynamics 365 CRM apps and Power Platform — what it is, why it's more than a database.
- Dataverse data model fundamentalsThe Dataverse data model — tables, columns, relationships, choices, security roles, and how it sits under Dynamics 365 and the Power Platform.
- 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.
Browse every guide in Customer Engagement or just Dataverse platform.
Was this helpful?
Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.
Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.