When working with Microsoft Dataverse or Dynamics 365, relationships between tables are more than just lookups. They define what happens to related child records when actions occur on a parent record—such as delete, assign, share, or reparent.
Choosing the wrong behavior can lead to:
- Accidental mass deletion
- Unexpected ownership changes
- Unwanted access sharing
- Broken relationships
- Data inconsistency
This guide explains all relationship behaviors in a clear and practical way.
What Is Relationship Behavior?
A relationship behavior controls how child records react when something happens to the parent record.
Example:
- Parent = Account
- Child = Contact
What should happen to Contacts when the Account is deleted, reassigned, shared, or merged?
That answer depends on the behavior you configure.
Main Types of Relationship Behavior
There are three main options:
- Referential
- Parental
- Custom
Let’s break each one down.
1. Referential Behavior
Referential behavior keeps parent and child records linked, but child records do not fully inherit parent actions.
You define limited behavior for delete scenarios.
Referential – Restrict Delete
| Section | Details |
|---|---|
| Scenario | A parent record has related child records. |
| What Happens? | The parent record cannot be deleted until child records are removed or reassigned. |
| Best Use Case | Use when child records must be reviewed before deleting the parent. |
| Example | You cannot delete an Account if Contacts still exist under it. |
| Benefit | Prevents accidental data loss. |
Referential – Remove Link Delete
| Section | Details |
|---|---|
| Scenario | A parent record has related child records. |
| What Happens? | The parent record can be deleted, and child records remain, but the relationship is removed. The lookup field on child records is cleared. |
| Important Note | This works only when the lookup field is optional. |
| Best Use Case | Use when child records can exist independently. |
| Example | Delete a Campaign, but related Leads remain without a Campaign reference. |
2. Parental Behavior
Parental behavior means child records strongly depend on the parent.
Most actions performed on the parent automatically cascade to child records.
This is the most powerful—and most risky—behavior.
How Parental Behavior Works
With parental behavior:
- Deleting parent deletes children
- Assigning parent changes child ownership
- Sharing parent shares children
- Changing parent lookup updates hierarchy
- Merging parent records moves children to the master record
Example Actions in Parental Behavior
Delete Parent: Deleting the parent also deletes all related child records.
⚠️ Risk: One delete can remove large amounts of data.
Assign Parent: Changing owner of the parent also changes owners of child records.
⚠️ Risk: Ownership across the hierarchy may change unexpectedly.
Share Parent: Sharing the parent automatically shares child records.
⚠️ Risk: Users may gain access to records they were not meant to see.
Change Parent Lookup: If the relationship changes, child hierarchy updates automatically.
Merge Parent Records: Child records move to the surviving master record.
When Should You Use Parental Behavior?
Use only when:
- Child cannot exist without parent
- Data is tightly dependent
- You want built-in automation without Power Automate or plugins
Good Examples
- Order → Order Lines
- Invoice → Invoice Items
- Case → Case Activities
When to Avoid Parental Behavior
Avoid when:
- Child records are independent
- Security access must remain separate
- Ownership should not change automatically
- Deleting parent should not remove history
3. Custom Relationship Behavior
Custom behavior gives you full control over each action separately.
You can configure cascade rules for:
- Assign
- Share
- Unshare
- Delete
- Reparent
This is the most flexible option.
Assign Behavior Options
Controls what happens when parent ownership changes.
| Configuration | Explanation |
|---|---|
| Cascade All | All related child records are assigned to the new owner |
| Cascade Active | Only active child records are reassigned |
| Cascade User-owned | Only child records owned by the same user as parent are reassigned |
| Cascade None | Only parent owner changes |
Share Behavior Options
Controls what happens when the parent is shared.
| Configuration | Explanation |
|---|---|
| Cascade All | Share parent and all child records |
| Cascade Active | Only active child records are shared |
| Cascade User-owned | Only child records owned by same user are shared |
| Cascade None | Only parent is shared |
Unshare Behavior Options
Controls what happens when shared access is removed.
| Configuration | Explanation |
|---|---|
| Cascade All | Remove access from parent and all child records |
| Cascade Active | Remove access only from active child records |
| Cascade User-owned | Remove access from child records owned by same user |
| Cascade None | Only parent is unshared |
Delete Behavior Options
Controls what happens when the parent is deleted.
| Configuration | Explanation |
|---|---|
| Cascade All | Delete parent and all child records |
| Remove Link | Delete parent, keep children, clear lookup |
| Restrict | Prevent delete if child records exist |
Reparent Behavior Options
Controls what happens when a child is moved to another parent.
| Configuration | Explanation |
|---|---|
| Cascade All | All child records update to new parent hierarchy |
| Cascade Active | Only active child records update |
| Cascade User-owned | Only child records owned by same user update |
| Cascade None | No automatic update; manual handling required |
Quick Comparison Table
| Behavior Type | Best For | Risk Level | Flexibility |
|---|---|---|---|
| Referential | Independent records | Low | Medium |
| Parental | Strong dependency | High | Low |
| Custom | Controlled business logic | Medium | High |
Real-World Recommendation
Use Referential When:
- Child records can survive without parent
- You want safe deletes
- Ownership/security should remain separate
Use Parental When:
- Parent and child are tightly linked
- Full automation is desired
- Child lifecycle depends on parent
Use Custom When:
- Business rules vary by action
- You need granular control
- Security and ownership rules are complex
Common Mistakes to Avoid
1. Using Cascade Delete Without Thinking
May remove thousands of related records.
2. Auto Ownership Changes
Can disrupt queues, teams, and reporting.
3. Over-sharing Data
Cascade share may expose sensitive records.
4. Ignoring Inactive Records
Cascade Active behaves differently than Cascade All.
Final Thoughts
Relationship behavior is one of the most important configuration decisions in Dataverse and Dynamics 365.
A simple lookup can have major consequences depending on the cascade rules behind it.
Before creating any relationship, ask:
- Should child records survive independently?
- Should ownership follow the parent?
- Should security cascade automatically?
- What happens if parent is deleted?
Choose carefully, and your system stays clean, secure, and scalable.
If you liked the post, please share it with others 🙂
Please feel free to comment if you are stuck in any step
Thank you for reading 🙂
Leave a Reply