What happens to a child record when its parent is deleted depends entirely on the relationship type and, for lookups, on the delete behavior you configured. Salesforce gives you three explicit choices on Lookup, and a single mandatory cascade behavior on Master-Detail.
Master-Detail — cascade delete (always)
Deleting the master automatically deletes every child (and their children if you have a 3-level chain). This is part of Master-Detail’s definition — you cannot turn it off.
Specifics:
- Children are moved to the Recycle Bin along with the parent.
- They stay in the Recycle Bin for 15 days (or until quota fills).
- Undeleting the parent within 15 days restores the parent and the children.
- If you delete a child directly (not via cascade), the parent is unaffected.
- Cascade flows through up to 3 levels of master-detail nesting.
This makes Master-Detail unsafe for relationships where the child has independent business meaning — you’d lose all your invoices if someone deleted an Account by mistake. Use Lookup for that scenario.
Lookup — three configurable delete behaviors
When creating a Lookup field, Salesforce asks: “What should happen to this field when the lookup record is deleted?” The three options:
1. Clear the value of this field (default)
The lookup is set to null on every child record. The child stays, just no longer points anywhere. This is the safest default — no data is lost, but the relationship breaks.
After this, any required-field, validation rule, or business logic that expected the lookup to be populated may start failing on subsequent edits of the child.
2. Don’t allow deletion of the lookup record that’s part of a lookup relationship
The platform blocks the parent’s delete with a user-facing error if any child still references it. Users must manually clear or reassign the children first.
This is essentially a referential integrity guard — useful for vendor/supplier records that should never be deleted while in use.
3. Delete this record also (cascade-like on a Lookup)
When the parent is deleted, this child is also deleted. The option only appears if:
- The lookup is Required
- The relationship is from a custom object to a standard or custom object (with restrictions)
This effectively gives you cascade-delete without the other strictures of Master-Detail (no ownership inheritance, no roll-ups), but it’s narrower in scope and applied per-field.
External Lookup / Indirect Lookup
External lookups don’t fully cascade because the external system owns the data. Behavior when the related external record disappears:
- The field’s display value becomes invalid/empty next time the row is queried via Salesforce Connect
- No automatic Salesforce-side cleanup
For Indirect Lookup (external child → Salesforce parent): deleting the Salesforce parent has the same options as a regular Lookup, plus the external child rows in their source system are unaffected unless you’ve built sync logic.
Hierarchical Relationship (User)
If a user record has the manager set to another user, and that manager is deleted:
- The system enforces that you can’t fully delete a user account in Salesforce (you deactivate them).
- But during deactivation, references in
ManagerIdare usually left intact; the manager just becomes inactive. Reassignment is your job.
Self-relationships
For a custom self-lookup (e.g., Account.ParentId), the same three delete options apply. Most commonly:
- Top-level Account deleted → children’s ParentId set to null (becomes top-level) — option 1
- Or you block deletion if children exist — option 2
For custom self-master-detail, cascade is automatic — deleting any node deletes its entire subtree.
Recycle Bin behavior summary
| Relationship | Delete behavior | Recycle Bin |
|---|---|---|
| Master-Detail | Cascade (always) | Parent + children both restorable for 15 days; restoring parent restores children |
| Lookup — Clear | Lookup nulled; child stays | Only the parent goes to Recycle Bin |
| Lookup — Block | Parent delete blocked entirely | N/A — delete never happens |
| Lookup — Cascade | Parent + child to Recycle Bin | Restoring parent does not automatically restore the children (you must restore each side separately) |
This last row is a common gotcha: cascading via a Lookup option is not symmetric with master-detail. The two cascades look similar at delete time but behave differently at undelete time. Use Master-Detail when you want symmetric, transactional cascade behavior.
What about triggers?
before delete / after delete triggers on the child fire when the cascade reaches it. So a master-detail cascade will run all your existing child delete triggers — be sure they handle the cascade gracefully (don’t assume the parent still exists in the same transaction).
Bottom line
Master-Detail = mandatory cascade, symmetric undelete. Lookup = pick clear / block / cascade per field; undelete is per record, not symmetric. Choose based on whether children are conceptually part of the parent or related to it.
Verified against: Salesforce Help — Delete Behavior of Relationship Fields. Last reviewed 2026-05-17.