Overview
Parent-child (self-referencing) relationships allow records in a single table to relate to other records in the same table, creating hierarchical structures. This pattern is essential for organizational charts, project breakdowns, category trees, and any scenario requiring nested data.
Prerequisites
- Understanding of Dataverse tables and basic relationships
- Familiarity with one-to-many relationship concepts
- A Dataverse table already created for testing
- Maker permissions in a non-Default environment
What is a Parent-Child Relationship?
A parent-child relationship (also called a self-referencing or hierarchical relationship) is a special type of one-to-many relationship where both the parent and child records exist in the same table. Instead of linking two different tables together, records in one table link to other records in that same table.
Common real-world examples:
| Scenario | Parent Record | Child Records |
|---|---|---|
| Organizational chart | Manager | Direct reports (employees) |
| Project structure | Parent project | Sub-projects or phases |
| Task breakdown | Parent task | Subtasks |
| Product categories | Main category (Electronics) | Subcategories (Laptops, Phones, Tablets) |
| Account hierarchies | Parent company | Subsidiary companies |
| Location structure | Region | Sites within that region |
Why use parent-child relationships?
- Flexible depth – Support unlimited hierarchy levels without creating new tables
- Simplified data model – One table instead of separate tables for each hierarchy level
- Easy navigation – Users can drill down through parent-child chains naturally
- Consistent structure – All records share the same fields regardless of hierarchy level
- Roll-up calculations – Aggregate data up the hierarchy (total budget from all child projects)
Understanding the Technical Structure
Technically, a parent-child relationship is just a standard one-to-many relationship where the "Related Table" is the same as the "Current Table". This creates a lookup column that points back to the same table.
Example: Employee organizational chart
In an Employee table with a parent-child relationship:
- Each Employee record has a "Manager" lookup field
- The Manager lookup points to another Employee record (the manager)
- The CEO has no manager (Manager field is blank)
- Each manager can have multiple direct reports (employees whose Manager field points to them)
This creates a hierarchy:
CEO (Manager = blank)
├── Director of Operations (Manager = CEO)
│ ├── Operations Manager (Manager = Director of Operations)
│ └── Facilities Manager (Manager = Director of Operations)
└── Director of Finance (Manager = CEO)
├── Financial Controller (Manager = Director of Finance)
└── Accountant (Manager = Director of Finance)Key technical points:
- The lookup column is created in the same table it references
- Records at the top of the hierarchy have blank/null parent lookups
- Records can exist at any level—there's no enforced maximum depth
- Circular references are possible but should be prevented (Employee A reports to Employee B who reports to Employee A)
Creating a Self-Referencing Relationship
Creating a parent-child relationship follows the same process as creating any one-to-many relationship, except you select the current table as the "Related Table".
Step-by-step creation:
- Navigate to your table (e.g., Employee, Project, Category)
- Click Relationships in the top navigation
- Click + New relationship → One-to-Many
- In the "Related Table" dropdown, select the same table you're currently in
- Configure the lookup column name (e.g., "Parent Project", "Manager", "Parent Category")
- Set cascade behavior (explained below)
- Click Done to create the relationship
The system creates a lookup column with the name you specified. This lookup displays all records from the same table, allowing users to select a parent record.
Choosing the Right Cascade Behavior
Cascade behavior becomes critically important in parent-child relationships because deleting a parent can affect an entire branch of the hierarchy tree.
Cascade behavior options and their impact:
| Behavior | What Happens When Parent Deleted | Best For |
|---|---|---|
| Cascade All | Deletes all child records, grandchildren, and entire subtree | Project structures where sub-projects are meaningless without parent |
| Remove Link | Clears parent lookup in children; they become top-level records | Organizational charts (employees don't disappear when manager leaves) |
| Restrict | Prevents deletion if any child records exist | Category trees (can't delete parent category while subcategories exist) |
Example scenarios:
Cascade All (Project Structure):
You're managing a construction project with sub-projects for Foundation, Framing, and Electrical work. Each sub-project has further task breakdowns. If you delete the main Construction project, all sub-projects and their tasks are deleted automatically—they're meaningless without the parent context.
DELETE: Construction Project
Result: Foundation (deleted), Framing (deleted), Electrical (deleted)
+ All tasks under each sub-project (also deleted)Remove Link (Organizational Chart):
When a manager leaves the organization and their Employee record is deleted, their direct reports don't disappear. Instead, the "Manager" field on those employees is cleared, and they temporarily become top-level records until reassigned to a new manager.
Remove Link (Organizational Chart):
When a manager leaves the organization and their Employee record is deleted, their direct reports don't disappear. Instead, the "Manager" field on those employees is cleared, and they temporarily become top-level records until reassigned to a new manager.
DELETE: Operations Director
Result: Operations Manager (Manager = blank)
Facilities Manager (Manager = blank)
Both employees still exist, now unassignedRestrict (Category Tree):
Your product catalog has Electronics → Laptops → Gaming Laptops. You cannot delete "Electronics" while "Laptops" exists, and you cannot delete "Laptops" while "Gaming Laptops" exists. This prevents accidentally destroying your category structure.
DELETE: Electronics category
Result: ERROR - Cannot delete because child categories exist
Action: Must delete or reassign all subcategories firstVisualising Parent-Child Data in Model-Driven Apps
Model-Driven Apps provide built-in visualizations for hierarchical data. Once you've created a parent-child relationship, you can display it in two ways: subgrids and hierarchy charts.
Subgrid approach (traditional list):
Add a subgrid to the parent record's form showing all child records. This displays children as a standard grid—functional but doesn't convey hierarchy visually.
- Edit the table's Main form
- Add a subgrid component to the form
- Set the subgrid's data source to the parent-child relationship
- Users see a list of child records when viewing the parent
Hierarchy visualization (tree view):
For deeper hierarchies, enable the hierarchy visualization feature. This displays records in an expandable tree structure showing multiple levels at once.
- Navigate to your table → Settings → Hierarchy Settings
- Click Enable Hierarchy
- Select the parent-child relationship to visualize
- Choose which fields to display in the tree (typically Name, Status, Owner)
- Save and publish
Users can now click the hierarchy icon on any record to see an interactive tree showing parents, siblings, and children with expand/collapse functionality.
Real-World Parent-Child Scenarios
Parent-child relationships solve specific business problems where data naturally forms hierarchies. Here are proven implementations:
1. Organizational Chart (Employee Management):
Setup:
- Employee table with "Manager" lookup to Employee
- Cascade behavior: Remove Link (employees persist when manager leaves)
- Hierarchy visualization enabled showing reporting lines
Benefits:
- Automatically maintain org chart as people move roles
- Calculate team sizes by counting direct/indirect reports
- Show approval chains for workflows
- Generate skip-level lists (manager's manager)
2. Project/Task Breakdown Structure:
Setup:
- Project table with "Parent Project" lookup to Project
- Cascade behavior: Cascade All (sub-projects die with parent)
- Rollup columns to sum budgets/hours up the hierarchy
Benefits:
- Unlimited sub-project depth (Phase → Workstream → Task → Subtask)
- Aggregate costs/progress from bottom up
- Track dependencies within project families
- Filter views to show only top-level projects or drill into details
3. Product Category Tree:
Setup:
- Category table with "Parent Category" lookup to Category
- Cascade behavior: Restrict (prevent orphaning subcategories)
- Products link to Category via separate lookup
Benefits:
- Flexible catalog structure (Electronics → Computers → Laptops → Gaming)
- Move categories by changing parent without rebuilding structure
- Query all products in category and subcategories
- Display category breadcrumbs on product pages
4. Account Hierarchies (B2B Sales):
Setup:
- Account table with "Parent Account" lookup to Account
- Cascade behavior: Remove Link (subsidiaries exist independently)
- Rollup total revenue across corporate family
Benefits:
- Map corporate ownership structures
- Apply enterprise agreements to all subsidiary accounts
- Report revenue at parent company level
- Identify decision makers in parent organizations
Working with Parent-Child Data in Code
Querying hierarchical data requires recursive logic to traverse multiple levels. Power Platform provides tools to simplify this.
FetchXML with Hierarchical Queries:
Use the under and not-under condition operators to query hierarchies:
<fetch>
<entity name="cr6a3_project">
<attribute name="cr6a3_name" />
<filter>
<condition attribute="cr6a3_parentproject"
operator="under"
value="{PARENT-PROJECT-GUID}" />
</filter>
</entity>
</fetch>This returns all descendants of the specified parent project—children, grandchildren, and all levels below.
Canvas App Recursive Patterns:
Canvas Apps don't natively support recursive queries. You must build hierarchies iteratively:
// Get immediate children only
Filter(Projects, 'Parent Project'.ProjectID = varSelectedProject.ProjectID)
// For deeper hierarchies, use collections and loops
// This is complex - consider using Power Automate insteadPower Automate Flow Approach:
For complex hierarchy operations (calculate total descendants, find root parent, build breadcrumb paths), use Power Automate with "Apply to each" loops:
- Start with a specific record
- Query for child records where Parent = current record
- For each child, repeat step 2 recursively
- Track visited records to prevent infinite loops
Avoiding Parent-Child Relationship Problems
Problem 1: Circular References
Issue: Employee A reports to Employee B, who reports to Employee C, who reports back to Employee A—creating an infinite loop.
Solution:
- Add validation via Power Automate flow that checks for circular references before allowing saves
- Use JavaScript on the form to prevent users selecting descendants as parents
- Document business process rules requiring managers to exist higher in hierarchy
Problem 2: Orphaned Records After Bulk Deletes
Issue: Deleting multiple parent records with Remove Link cascade creates large numbers of orphaned top-level records.
Solution:
- Use Restrict cascade behavior to force manual reassignment before deletion
- Implement soft deletes (Status = Inactive) instead of hard deletes
- Create views to identify orphaned records (Parent = blank) for cleanup
Problem 3: Performance with Deep Hierarchies
Issue: Recursive queries on hierarchies 10+ levels deep timeout or slow down the system.
Solution:
- Limit hierarchy depth with validation (max 5-7 levels for most business scenarios)
- Add indexed "Level" integer field updated via workflow when parent changes
- Cache hierarchy data in collections for Canvas Apps rather than querying repeatedly
- Use rollup columns sparingly—they recalculate across entire subtrees
Problem 4: Confusing Parent-Child Lookup in Forms
Issue: Users see entire table list in parent lookup dropdown, including descendants—allowing selection of own children as parents.
Solution:
- Add JavaScript to filter lookup excluding current record and descendants
- Use business rules to show warnings when suspicious selections made
- Provide clear field help text: "Select the project this project belongs under"
Parent-Child Relationship Design Principles
Naming conventions:
- Use clear parent identifiers: "Parent Project", "Manager", "Parent Category"
- Avoid ambiguous names like "Related Project" or "Project Link"
- Name rollup columns with context: "Total Child Budget" not "Total"
- Use consistent terminology across all hierarchical tables
Data integrity:
- Add validation to prevent circular references
- Use Restrict cascade for master data (categories, accounts)
- Use Remove Link for transient hierarchies (org charts)
- Never use Cascade All unless subtrees are truly meaningless without parents
- Implement soft deletes for hierarchical data
Performance optimization:
- Index the parent lookup column for faster queries
- Limit hierarchy depth to 7 levels maximum for performance
- Add "Level" field to avoid recursive depth calculations
- Cache hierarchy paths as text for breadcrumb displays
- Use FetchXML hierarchical operators instead of manual recursion
User experience:
- Enable hierarchy visualization for complex trees (>3 levels)
- Provide breadcrumb navigation showing full parent chain
- Add subgrids showing both children and siblings for context
- Display level/depth on forms to help users understand position
- Create views for "Top Level Only" and "All Records" variants
- No circular reference validation
- Cascade All on all hierarchies
- Unlimited depth allowed
- No visualization enabled
- Circular reference prevention built in
- Thoughtful cascade behavior per scenario
- Max 7 levels enforced via validation
- Interactive tree view enabled
Next Steps
You now understand how to build and manage parent-child relationships in Dataverse. Expand your hierarchical data skills by exploring:
- Rollup columns for hierarchies – Aggregate child data up the tree (total budget, count of descendants)
- Power Automate hierarchy flows – Automate parent reassignment, calculate depths, detect circular references
- Custom hierarchy visualizations – Build Canvas App tree controls using PCF components
- Security inheritance – Propagate permissions down hierarchy branches automatically
- Multi-parent hierarchies – Use many-to-many relationships for matrix structures
The official Microsoft Dataverse hierarchical data documentation provides advanced guidance on querying hierarchies, performance optimization, and visualization options.