Cascading delete in Dataverse

When a Dataverse record is deleted, what happens to its related records? Cascading behaviour — configured per relationship — determines whether children are deleted too, whether the parent's deletion is blocked, or whether the relationship is simply broken. Getting these settings right matters; wrong settings produce surprising data loss or surprising deletion failures.

The cascade options.

Each 1:N (one-to-many) relationship in Dataverse has cascade settings for several operations — Assign, Reparent, Share, Unshare, Merge, and most importantly Delete. For Delete, the options are:

• Cascade — when the parent is deleted, all child records are also deleted. The whole subtree disappears together.
• Restrict — block the delete of the parent if child records exist. The user must delete children first or the operation fails.
• Remove Link — delete the parent but break the relationship (set the child's lookup to null). The children survive but become orphans.
• Cascade Active — like Cascade but applies only to active child records; inactive ones are left behind.
• Cascade User-Owned — cascade applies only to children owned by the same user; others have their link removed.

Common patterns.

• Account → Contacts (typical default: Cascade) — when an Account is deleted, its child Contacts are deleted too. Reasonable when the Account's deletion means the whole customer relationship is gone.

• Account → Cases (often configured: Restrict) — don't let the Account be deleted while it has open cases. Forces explicit handling of pending work.

• Opportunity → Quote (typical: Cascade) — closing or deleting an opportunity should cascade to its draft quotes.

• Contact → Email Address Detail (typical: Cascade) — contact-specific child data follows the contact.

• System User → Owned Records (typical: Restrict at user record, or specific reassignment workflow on departure) — users leaving the company should have their records reassigned rather than orphaned or lost.

Designing cascade behaviour. When creating a relationship between two custom tables, choose:

• Cascade when the child's existence makes no sense without the parent. A Sales Order Line makes no sense without the Sales Order; cascade.
• Restrict when the child has independent value or business meaning. A Customer has Cases; deleting the Customer shouldn't lose case history.
• Remove Link rarely the right choice — orphans are usually unintended.

Performance. Deep cascade chains can produce slow operations. Deleting an Account that cascades to Contacts that cascade to Activities that cascade to Notes can run for seconds or minutes if the subtree is large. Plan for this with admin operations.

Cascade and bulk delete. Bulk delete jobs respect cascade settings — deleting a thousand parents can multiply to tens of thousands of cascaded deletes. Plan capacity.

Cascade and audit. When records are cascade-deleted, the audit log records each deletion. For audit-sensitive scenarios, ensure the audit is comprehensive enough to reconstruct the deletion chain.

Cascade and integrations. Integrations that watch for deletion events (via webhooks, change tracking, or Service Bus) receive notifications for each deleted record in the cascade. High-volume cascades can flood integration consumers.

Cascade vs deactivation. A frequently-better pattern: deactivate rather than delete. Deactivated records remain in the database with an Inactive status; relationships are preserved; reporting can include or exclude them. Cascade behaviour applies only to actual deletes.

For records that genuinely shouldn't survive the parent's removal (transient child data, draft documents), deletion makes sense. For records with audit / historical value, deactivation is safer.

Configuration vs default. Each table has default cascade configurations on its system relationships. Custom relationships can be configured per integration intent. Auditing the cascade settings on critical tables is part of solution review.

Common pitfalls.

• Cascade where Restrict was intended — accidentally deleting child records that should have been preserved. Reversal through point-in-time restore is the recovery, with data loss between backup and now.
• Restrict where Cascade was intended — deleting a parent fails with "child records exist" errors; user can't tell what to do.
• Remove Link causing orphan accumulation — orphan child records pile up with no parent; reporting becomes inconsistent.
• Cascade chain unintentionally deep — a delete propagates further than expected, removing data the operator didn't realise would be touched.

Audit recommendation. Before activating an environment for production, audit cascade settings on critical tables. Document the intended behaviour. Test deletion scenarios. The cost of audit is small; the cost of surprise data loss is enormous.

Operational reality. Cascade settings are part of the data-model contract. Get them right at design time; they're hard to change safely once data accumulates. When in doubt, prefer Restrict — failed deletes are recoverable; cascade data loss isn't.