Designing Dataverse Hierarchical Relationships and Rollup Security: Modeling Parent-Child Table Hierarchies, Hierarchical Security Roles, and Visualizing Tree Structures in Model-Driven Apps

Introduction

Imagine you're building a field service management system for a national utilities company. Technicians report to supervisors, supervisors report to regional managers, and regional managers report to a national operations director. Each level needs to see its own records and the records of everyone below it — but not sideways, and definitely not upward. Meanwhile, you want a rollup column that automatically sums the total estimated repair hours across every job in a supervisor's entire team tree. And you want to display the organizational structure as an actual interactive hierarchy in the model-driven app so dispatchers can visually navigate it.

This is the moment when most Power Platform developers realize that standard security roles and lookup relationships won't cut it. You need Dataverse's hierarchical features: self-referential parent relationships, hierarchical security, the Manager hierarchy or Custom hierarchy models, and the tree visualization control built into model-driven apps. Getting these right requires understanding not just the configuration steps but the architectural decisions underneath — because mistakes at this level are expensive to unwind.

By the end of this lesson, you'll be able to design self-referential hierarchies in Dataverse, configure hierarchical security so managers automatically inherit access to their reports' records, wire up rollup columns that aggregate data across the entire subtree, and display navigable tree structures in your model-driven app. You'll also understand where each approach breaks down and how to architect around those limits.

What you'll learn:

• How to model self-referential parent-child relationships in Dataverse tables
• The difference between Manager Hierarchy and Custom Hierarchy security models, and when each applies
• How to configure hierarchical security roles that propagate access down a reporting chain
• How rollup columns interact with hierarchical relationships for multi-level aggregation
• How to enable and customize the hierarchy visualization control in model-driven apps
• Edge cases, performance traps, and architectural trade-offs at scale

---

Prerequisites

You should be comfortable with the core Dataverse concepts covered in Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers. You should understand one-to-many relationships and cascade behaviors — if those feel shaky, review Configuring Dataverse Table Relationships in Model-Driven Apps: One-to-Many, Many-to-Many, and Cascade Behaviors Explained first. You should also have a working understanding of Dataverse security roles and business units, as covered in Dataverse Security: Business Units, Security Roles, and Teams. Familiarity with rollup columns will help; if you need a primer, see Formula Columns and Rollup Columns in Dataverse: Calculated Data Without Code.

---

Understanding What "Hierarchical" Means in Dataverse

Before writing a single line of configuration, you need to understand the three distinct features that the word "hierarchical" covers in Dataverse. Conflating them is the most common source of confusion.

Hierarchical relationships are self-referential one-to-many relationships on a single table. A row of type Account can have a parent Account. A row of type Position can have a parent Position. The relationship column points back to the same table. This is purely a data modeling concept — it defines the tree structure in your data.

Hierarchical security is a security model that uses either the system User table's manager chain or a custom hierarchical relationship on a custom table to automatically grant a manager read (and optionally write) access to records owned by their direct and indirect reports. This is a security enforcement concept.

Hierarchy visualization is a UI feature in model-driven apps that renders rows in a tree diagram so users can navigate parent-child relationships visually. This is a presentation concept.

These three things are related but independent. You can have a hierarchical relationship without using hierarchical security. You can use hierarchical security with the built-in Manager model without any custom hierarchical relationship. You can enable hierarchy visualization on any self-referential relationship. Understanding which problem each feature solves prevents you from over-engineering a solution.

---

Modeling a Self-Referential Parent-Child Relationship

Why Self-Referential, Not a Separate Table

The instinct for many developers coming from relational backgrounds is to create a separate junction or tree table. Resist this for most organizational hierarchy scenarios. Dataverse's hierarchical features (both security and visualization) require a self-referential lookup column on a single table — a column on the table that points to another record of the same table type.

The benefits of the self-referential model:

• Dataverse natively understands the depth and lineage
• Rollup columns can aggregate across hierarchical depth
• The hierarchy visualization control works automatically
• Hierarchical security plugs directly into the relationship

The limitation: each row can have only one parent (it's a tree, not a graph). If your business domain requires a row to belong to multiple parent hierarchies, you need a different approach — but that's a relatively rare requirement for organizational structures.

Creating the Hierarchical Relationship

Let's use a concrete scenario: a Service Region table that represents geographic coverage zones, where regions can contain sub-regions to arbitrary depth (National → Regional → District → Local).

In Power Apps maker portal, navigate to your solution, find the Service Region table, and go to the Relationships tab.

Create a new Many-to-One relationship where:

• Related table (one side): Service Region (the same table — this is what makes it self-referential)
• Lookup column display name: Parent Region
• Lookup column name: new_parentregionid
• Relationship behavior: Configurable (more on this shortly)

When you set the related table to the same table you're currently editing, Dataverse knows this is a potential hierarchy candidate.

After creating the relationship, go back to the relationship definition and look for the Hierarchical checkbox or toggle (labeled "Hierarchical relationship" in the classic interface, or toggled under the relationship properties in the modern maker portal). Enable it. This is the single most important step — without it, you have a self-referential lookup but Dataverse doesn't treat it as a formal hierarchy.

Cascade Behavior Considerations

For hierarchical relationships, cascade behavior deserves careful thought. The default Parental cascade behavior means that when you delete a parent region, Dataverse will cascade delete all child regions. For organizational structures, this is usually dangerous — deleting a district shouldn't wipe out all its local regions.

Instead, consider Referential with a Restrict delete behavior: attempting to delete a parent that still has children raises an error and prevents the deletion. This forces a deliberate restructuring before removal, which is usually the correct behavior for organizational trees.

---

Designing Your Hierarchy Data Model for Real-World Complexity

The Flat-Flag Pattern vs. True Hierarchy

A tempting shortcut is to add a Region Type choice column (National, Regional, District, Local) and use it instead of a true parent relationship. Don't do this. The flat-flag pattern breaks down immediately when:

• You need to query "all districts under a given regional manager" — this requires multiple queries or complex LINQ
• The depth of your hierarchy changes (a new "Zone" level between Regional and District requires schema changes)
• You want rollup aggregation across levels
• You want hierarchy visualization

The true self-referential relationship handles all of these gracefully. Keep the type column if it helps with filtering or business logic, but the parent relationship should be the source of truth for the structure.

Handling Multiple Hierarchy Types in One App

Complex enterprise apps sometimes need two or more hierarchy dimensions on the same entity. For example, a workforce management app might need:

1. An org chart hierarchy (who reports to whom)
2. A cost center hierarchy (which cost center does this employee's expense roll up to)

Since only one self-referential relationship can be the designated hierarchy, you have two options:

Option A: Separate tables. Create an Org Chart Node table and a Cost Center table, each with their own hierarchical relationship. Relate the primary entity (like Worker) to both. This is architecturally clean but requires more complex querying.

Option B: Hierarchical for the primary, custom rollup logic for the secondary. Mark the org chart relationship as the hierarchy. For cost centers, build rollup logic using Power Automate cloud flows or calculated columns that traverse the cost center lookup manually. This is less elegant but keeps everything in one primary table.

For most scenarios, Option A is preferable because it keeps each hierarchy clean and queryable independently.

---

Hierarchical Security: Giving Managers Automatic Access

This is where things get genuinely powerful — and genuinely complex. Hierarchical security in Dataverse means that a user positioned higher in a hierarchy automatically gets read access (and optionally write access) to records owned by users below them, without needing explicit record sharing.

Two Hierarchy Models

Dataverse offers two distinct models for hierarchical security:

Manager Hierarchy: Uses the Manager field on the system User (SystemUser) table. When you set User A's manager to User B, User B automatically gets hierarchical access to records owned by User A. This model is straightforward and ties directly to your Azure Active Directory org chart if you sync manager relationships through Entra ID. The downside: it's entirely based on the User table's built-in manager field. You cannot use a custom table's hierarchy for this model.

Custom Hierarchy (Position Hierarchy): Uses the Position table (which is a system table in Dataverse), which has a built-in hierarchical self-reference. Users are assigned to positions, positions have parent positions, and the hierarchy is inferred from the position tree. This model is more flexible because the position hierarchy can be structured differently from the actual manager chain — useful when organizational security domains don't match the org chart exactly.

Enabling Hierarchical Security

To enable this feature, navigate to the Power Platform Admin Center, select your environment, go to Settings → Users + Permissions → Hierarchical Security. Here you'll find:

• The toggle to enable hierarchical security for the environment
• The choice between Manager and Custom hierarchy model
• The Depth setting (default: 3)

The depth setting is critical and often overlooked. A depth of 3 means a manager can see records owned by users up to 3 levels below them. If your org has 6 levels and you leave depth at 3, vice presidents won't see the records of front-line technicians. Set depth to match your deepest hierarchy level, but understand the performance implication: larger depths mean Dataverse evaluates more users when checking record access.

Configuring Security Roles for Hierarchical Security

Hierarchical security doesn't replace your standard security roles — it augments them. A user must still have a security role that grants at least User level access to a table. The hierarchical security then extends that to include records owned by subordinates up to the configured depth.

The permission levels involved:

• Read Direct Reports: The manager gets the same read privileges they have on their own records, applied to their direct and indirect reports' records
• Write Direct Reports: Optionally, managers can also be granted write/update privileges on subordinates' records

Configure this in the Hierarchical Security settings section in the admin center, where you can specify whether managers get Read Only or Read-Write access to subordinate records.

A concrete example: You have a Service Job table. A Field Technician with User-level access can see their own jobs. You configure hierarchical security at depth 4. Now their supervisor, who has the same security role (User-level), automatically sees all jobs owned by every technician under them in the hierarchy — no additional security role configuration, no record sharing, no views filtered by team membership.

When Hierarchical Security Falls Short

Hierarchical security is elegant for "I should see everything my subordinates own" scenarios, but breaks down in several common cases:

Cross-hierarchy visibility: A compliance officer who needs to see records across multiple branches of the hierarchy. Solution: use record sharing or a broader security role with Business Unit-level access for those specific users.

Non-ownership-based access: If access should be based on a field value (the territory assigned to a job) rather than who owns the record. Solution: combine hierarchical security with custom business logic, or use a different access pattern like security roles with filters.

Temporary delegation: An employee covering for a colleague while on leave. Hierarchical security doesn't support time-bounded access. Solution: explicit record sharing with an expiration convention enforced by a flow.

For these patterns, you'll typically combine hierarchical security with the field-level and record-sharing capabilities covered in Column-Level Security and Record Sharing in Dataverse.

---

Rollup Columns and Hierarchical Aggregation

Once your hierarchical relationship is in place and designated as the hierarchy, rollup columns gain a superpower: they can aggregate across the entire subtree, not just direct children.

Standard Rollup vs. Hierarchical Rollup

A standard rollup column on the Account table might sum the revenue of all directly related Opportunities. A hierarchical rollup on the Account table sums the revenue of Opportunities related to the account and all of its descendant accounts, to any configured depth.

This distinction matters enormously for our Service Region scenario. If you want a District region's Total Estimated Hours to reflect the sum of all jobs across every Local region beneath it, you need a hierarchical rollup — a standard rollup would only capture jobs directly on the District record itself.

Configuring a Hierarchical Rollup Column

Navigate to your Service Region table, add a new column, and select Rollup as the column type. As described in Formula Columns and Rollup Columns in Dataverse: Calculated Data Without Code, rollup columns have three sections: Source, Filter, and Aggregate.

For a hierarchical rollup, the key is in the Source section. You'll see the option to specify a relationship — and if your table has a designated hierarchical relationship, you'll see a Hierarchy option in the relationship type selector. Choose Hierarchy (all levels below) rather than a specific one-to-many relationship.

The configuration:

Source Entity: Service Region (self, all hierarchical descendants)
Related Entity: Service Job (via Service Region lookup)
Aggregate Function: SUM
Aggregate Column: Estimated Hours
Filter: Status = Active

When this rollup recalculates, Dataverse traverses the entire subtree beneath each region, finds all related Service Jobs across every descendant region, applies the Active status filter, and sums the hours.

Rollup Depth Limits and Performance

Hierarchical rollups have a maximum depth of 10 levels. If your tree exceeds 10 levels, the rollup stops at level 10 and doesn't aggregate beyond that. This is a hard platform limit.

Performance considerations for rollups on large hierarchies:

• Each parent in the hierarchy triggers its own rollup calculation job
• If you have 1,000 region nodes in your hierarchy and a record updates a leaf node, Dataverse must recalculate rollups for all ancestor nodes up the chain
• For wide, shallow hierarchies this is manageable; for narrow, deep hierarchies with frequent data changes, the recalculation queue can become a bottleneck

For high-volume scenarios, consider whether a Power Automate flow that explicitly calculates and writes the aggregate on a scheduled basis gives you more control than the native rollup mechanism. The native rollup is elegant for moderate data volumes; for millions of rows, custom aggregation gives you scheduling control and can run incrementally.

---

Querying Hierarchical Data: FetchXML and the Hierarchy Operators

Understanding how to query hierarchical data programmatically is essential for building custom views, reports, and integrations. Dataverse provides native FetchXML operators for hierarchical queries that are far more efficient than recursive loops.

The Hierarchy Condition Operators

Dataverse adds five condition operators specifically for hierarchical queries:

• above: Returns all ancestors of a specified row (all rows above it in the tree)
• eq-or-above: Returns the row itself and all ancestors
• under: Returns all descendants of a specified row (the entire subtree below it)
• eq-or-under: Returns the row itself and its entire subtree
• not-under: Returns all rows that are NOT descendants of a specified row

These operators work only on the column designated as the hierarchical relationship — not on arbitrary lookup columns.

A FetchXML query to get all Service Jobs belonging to Service Regions under a specific region (say, the "Southwest Region" with a known GUID):

<fetch>
  <entity name="new_servicejob">
    <attribute name="new_name" />
    <attribute name="new_estimatedhours" />
    <attribute name="new_status" />
    <link-entity name="new_serviceregion" 
                 from="new_serviceregionid" 
                 to="new_serviceregionid" 
                 alias="region">
      <filter>
        <condition attribute="new_parentregionid" 
                   operator="eq-or-under" 
                   value="{12345678-1234-1234-1234-123456789abc}" />
      </filter>
    </link-entity>
  </entity>
</fetch>

Notice that the condition is on new_parentregionid — the hierarchical lookup column — and the operator eq-or-under traverses the entire subtree including the specified region itself.

This single query replaces what would otherwise be a recursive series of queries. The performance advantage is substantial: a recursive approach on a 6-level deep hierarchy with 100 nodes per level would require up to 7 separate queries (one per level). The eq-or-under operator does it in one.

Using Hierarchy Operators in Power Automate

In a Power Automate flow using the Dataverse connector, you can't directly write FetchXML in the "List rows" action's filter fields — but you can use the List rows action with a custom FetchXML via the "Fetch XML query" parameter (visible when you switch to advanced mode or use the "Fetch XML query" field directly in the newer connector).

Paste the FetchXML directly into that field, parameterizing the GUID:

<fetch>
  <entity name="new_serviceregion">
    <attribute name="new_serviceregionid" />
    <attribute name="new_name" />
    <filter>
      <condition attribute="new_parentregionid" 
                 operator="under" 
                 value="@{triggerOutputs()?['body/new_serviceregionid']}" />
    </filter>
  </entity>
</fetch>

This pattern is extremely useful for building notification flows, data synchronization, or delegation logic that needs to operate on "everyone below this manager."

---

Visualizing Hierarchies in Model-Driven Apps

Now for the part that makes the hierarchy tangible to users: the tree visualization control. When configured correctly, this gives users a clickable, pannable tree diagram where they can see the entire hierarchy of records, navigate to any node, and understand organizational structure at a glance.

Enabling the Hierarchy Control

The hierarchy visualization control is enabled at the view level, not the form level. Navigate to your solution, open the Service Region table, and go to the Views tab.

You don't create a special "hierarchy view" — instead, you enable hierarchy visualization on an existing public view. Open or create a view for Service Region (something like "All Service Regions"). In the view editor, look for the Hierarchy Settings option (in the classic solution explorer, this is under Settings → Hierarchy Settings; in the modern maker portal, look in the view's ellipsis/more options menu for "Hierarchy Settings").

In Hierarchy Settings, configure:

• Hierarchy relationship: Select the hierarchical relationship you designated earlier (the self-referential Parent Region lookup)
• Quick form: Select which quick view form appears when a user clicks a node in the tree — typically a compact summary form
• Lookup columns: Choose which columns appear in the tree nodes (up to 3 columns recommended; more than that makes the node tiles unreadable)

After enabling, when users navigate to the Service Region list view, they'll see a toggle button to switch between the grid view and the hierarchy view. The hierarchy view renders an interactive tree where each node shows the configured columns and clicking a node opens the quick view form — and from there, the full record form.

What the Tree Looks Like (and Its Limitations)

The tree renders top-down. The root node (a region with no parent) appears at the top. Branches expand downward. Users can expand/collapse nodes, pan the diagram, and click nodes to see details.

Limitations you should communicate to stakeholders before promising features:

• Maximum 1,500 nodes displayed: The tree visualization caps out at 1,500 records. For large hierarchies, the tree truncates. This is not configurable.
• No custom colors or icons per node: Nodes are uniform in appearance. You can't conditionally color a node red if a region has overdue jobs. If you need conditional formatting, you're looking at a custom PCF control.
• Read-only navigation: The hierarchy visualization is for browsing, not editing. Users click through to the full form to make changes.
• Performance on large trees: Loading a tree with 500+ nodes can be noticeably slow (3-5 seconds) on first render because Dataverse is fetching and constructing the relationship graph client-side.

For requirements that exceed these limits — custom node colors, actions directly on tree nodes, infinite tree depth, performance beyond 1,500 nodes — you'll need a custom Power Apps Component Framework (PCF) control. This is a significant build investment but gives you complete control over the tree rendering. You can learn more about that path in Extending Model-Driven Apps with PCF Controls: Building and Deploying Custom Field and Dataset Components for Dataverse Forms and Views.

Making Hierarchy Navigation Discoverable

One practical challenge with hierarchy views: users don't naturally discover the toggle between grid and hierarchy view on their own. Address this through:

1. A brief in-app notification or banner using the model-driven notification API or a simple business rule that fires on page load (though this is tricky to implement cleanly)
2. Custom command bar buttons — add a "View as Hierarchy" button to the command bar that programmatically activates the hierarchy view mode. See Customizing the Model-Driven Command Bar with Power Fx for how to wire this up
3. Training materials and embedded help text on the form or view

The toggle is visible once you know to look for it, but first-time users consistently miss it. Make it prominent.

---

Combining All Three Features: A Complete Architecture Walkthrough

Let's put everything together with our field service scenario and trace through how all three features interact.

The Domain Model

Tables:

• Service Region (hierarchical self-reference on Parent Region)
• Service Job (many-to-one to Service Region, owner is a User)
• User (system table, with Manager field populated from Entra ID sync)

Hierarchy structure:

National Operations (Level 1)
  ├── Southwest Region (Level 2)
  │   ├── Arizona District (Level 3)
  │   │   ├── Phoenix Local (Level 4)
  │   │   └── Tucson Local (Level 4)
  │   └── Nevada District (Level 3)
  └── Northwest Region (Level 2)
      └── ...

Users and their positions in the org:

• Carla (National Operations Director) → Manager: none
• Darnell (Southwest Regional Manager) → Manager: Carla
• Priya (Arizona District Supervisor) → Manager: Darnell
• Multiple technicians → Manager: Priya

How the Security Model Works

You've enabled Manager Hierarchy security at depth 4. Carla's security role gives her User-level read on Service Jobs (she can see her own). Via hierarchical security, she also gets read access to all Service Jobs owned by Darnell, Priya, and all technicians under Priya — automatically, with no record sharing required.

Priya can see her own jobs and all her technicians' jobs (depth 2). She can't see Darnell's jobs (upward access is never granted by hierarchical security). She can't see jobs in the Nevada District (sideways access is never granted).

This access pattern — downward visibility, no upward, no sideways — is exactly what most organizational security models need, and it's maintained automatically as the org chart changes. When you add a new technician under Priya in Entra ID, the next time their manager field syncs, Priya automatically gains access to their records.

How Rollups Work Across This Structure

On the Service Region table, you've configured a hierarchical rollup column Total Estimated Hours that sums the Estimated Hours column from all Service Jobs related to any Service Region in the subtree.

When you view the Arizona District record, Total Estimated Hours shows the sum of all active jobs from Phoenix Local AND Tucson Local AND any jobs directly attached to the Arizona District record itself. The rollup traverses all four hierarchy levels automatically.

When Priya looks at the Arizona District in the hierarchy tree view, she can see this aggregate without navigating into each local region. This is the direct business value: middle managers get rolled-up visibility without having to drill down manually.

The Visualization Brings It Together

With hierarchy visualization enabled on the Service Region table's "All Service Regions" view, Darnell logs in and switches to hierarchy view. He sees the Southwest Region node at the top of his visible tree, with Arizona District and Nevada District as children, and the four local regions beneath those. The quick view form on each node shows region name, assigned manager name, and the Total Estimated Hours rollup value.

He can immediately see that Tucson Local has 340 estimated hours this month while Phoenix Local has 85, without clicking into any individual records. That operational insight comes directly from the combination of hierarchical rollup data and hierarchy visualization — neither feature alone delivers it.

---

Hands-On Exercise

In this exercise, you'll build a minimal version of the Service Region hierarchy with security and visualization in a non-production environment.

Setup (15 minutes)

1. Create a new solution in your development environment. Add a new custom table: Service Region with the display name "Service Region" and schema name new_serviceregion.

2. Add the following columns to Service Region:

   • Region Name (Text, Required, max 100 chars) — this will become your primary name column
   • Region Type (Choice: National, Regional, District, Local)
   • Region Manager (Lookup to User/SystemUser table)
   • Total Estimated Hours — leave this for the rollup step

3. Create the self-referential relationship: go to Relationships on the Service Region table, add a Many-to-One relationship where the related table is also Service Region. Name the lookup column "Parent Region" (new_parentregionid). Set delete behavior to Restrict. Save.

4. Edit the relationship you just created and enable the Hierarchical toggle. Save.

Data Setup (10 minutes)

5. Add sample records manually or via import. Create at least:
   • 1 National record (no parent)
   • 2 Regional records (parent = the National record)
   • 2 District records under one of the Regional records
   • 2 Local records under one of the Districts

Rollup Column (10 minutes)

6. Create a companion table: Service Job with columns Job Name (Text), Estimated Hours (Whole Number), Service Region (Lookup to Service Region), and Status (Choice: Active, Closed).

7. On the Service Region table, add a new Rollup column Total Estimated Hours. Configure it to aggregate from Service Job via the Service Region lookup, SUM the Estimated Hours, filtering for Active status. Enable the Hierarchy option if available in your version (if not, a non-hierarchical rollup against direct children is still useful for the exercise).

8. Add several Service Job records attached to your local-level regions. Manually trigger recalculation on a district region and observe whether the hours from child regions roll up.

Hierarchy Visualization (10 minutes)

9. Navigate to the Service Region table's views. Open or create an "All Service Regions" public view that includes Region Name and Region Type columns.

10. Access Hierarchy Settings for this view. Select the Parent Region hierarchical relationship. Create or select a quick view form for Service Region that shows Region Name, Region Type, and Total Estimated Hours. Save the hierarchy settings.

11. Open your model-driven app, navigate to Service Regions, and toggle to the hierarchy view. Navigate the tree and click a node to verify the quick view appears.

Security Testing (15 minutes)

12. If you have access to configure users in your development environment: create two test users, set one as the manager of the other, assign both the same security role with User-level access to Service Job. Log in as the manager user and verify you can see Service Jobs owned by the subordinate user. Log in as the subordinate and verify they cannot see the manager's records.

---

Common Mistakes & Troubleshooting

"The hierarchy toggle doesn't appear in my view"

The hierarchy visualization toggle only appears on views of tables that have an active designated hierarchical relationship. Verify two things: (1) you've created a self-referential relationship on the table, and (2) you've enabled the Hierarchical flag on that specific relationship. If both are true and the toggle still doesn't appear, clear your browser cache and check whether your security role includes read access to the hierarchical relationship's metadata.

"Hierarchical security isn't working — managers can't see subordinate records"

The most common causes:

• Records are team-owned, not user-owned. Hierarchical security only applies to user-owned records. Check the owning user field on the records in question.
• Hierarchy depth is too shallow. If depth is set to 3 but the manager is 4 levels above the record owner, access won't propagate. Increase depth in the admin center.
• Manager field isn't populated. For Manager Hierarchy model, the SystemUser record's manager field must be set. Entra ID sync doesn't always populate this immediately — verify the field directly on the user record in Dataverse.
• The feature is enabled but not yet propagated. After enabling hierarchical security, it can take up to 24 hours for existing records to have their access recalculated. New records pick up the rules immediately.

"My rollup column shows incorrect or zero values"

Rollup columns are asynchronous. The value won't update immediately when child records change. Check:

• Has the rollup recalculation job run? Look in the System Jobs view for rollup recalculation entries.
• Is the filter condition matching the data you expect? Open the rollup column definition and trace through the filter logic against your actual data.
• For hierarchical rollups specifically: is the hierarchical relationship properly designated? If the hierarchy flag was removed and re-added, rollup definitions may need to be re-saved to pick up the relationship again.

"The hierarchy tree shows some nodes but not all"

If you have more than 1,500 records in the table, the tree truncates. The nodes shown are not guaranteed to be a specific subset — the truncation isn't "top of tree first" in all cases.

If you're under 1,500 records but still see missing nodes, verify that all records have the parent lookup populated correctly. Orphaned records (parent lookup pointing to a deleted record) won't appear in the tree in a predictable location.

"FetchXML hierarchy operators return no results"

The under, above, and related operators only work on the column that is designated as the hierarchical column. If you query against new_parentregionid on a table where new_parentregionid is NOT flagged as the hierarchical relationship, the operators will silently return no results rather than throwing an error. Verify the hierarchical flag is set correctly.

---

Architecture Trade-offs and Scaling Considerations

When to Use Business Units Instead of Hierarchical Security

Business units are Dataverse's primary security boundary mechanism. Hierarchical security is supplemental. If your organization's security model maps cleanly to business units (e.g., each region is a business unit), you may not need hierarchical security at all — standard Business Unit-level access on security roles accomplishes the same thing with less complexity.

Use hierarchical security when:

• Your security hierarchy doesn't match your business unit structure
• You want managers to automatically see subordinate records without manual administration
• Your org structure changes frequently enough that manual record sharing would be unmanageable

Use business units when:

• You need hard data isolation between organizational segments
• You need to grant access to an entire division without worrying about individual manager chains
• You need team-owned records to participate in the security boundary (business units work with team ownership; hierarchical security doesn't)

For a deeper discussion of business unit design, Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data covers the interaction between business units, teams, and roles in detail.

Performance at Scale: The Depth × Breadth Problem

Hierarchical security performance degrades quadratically as both depth and breadth increase. Each time a user requests access to a record, Dataverse evaluates the hierarchical chain. At depth 4 with 20 direct reports per manager, a single access check may evaluate hundreds of user records.

For environments with more than 5,000 users participating in hierarchical security, monitor your environment's access check latency. Signs of degradation: slowly loading views that should be fast, timeouts on record retrieval in workflows. Mitigations:

• Reduce hierarchy depth if full depth isn't actually needed
• Move users who need broad access to a security role with Business Unit-level access instead of relying on hierarchical propagation
• Consider partitioning the user base across multiple environments for truly massive organizations (though this is a drastic solution with major integration implications)

Hierarchy Depth vs. Flat-Wide Trade-offs

From a query performance perspective, a flat-wide hierarchy (many children at one level, shallow depth) performs better than a tall-narrow hierarchy (few children per level, deep depth). The hierarchical query operators traverse depth at query time, so deeper hierarchies mean more traversal work.

If your domain naturally produces deep chains (e.g., project tasks with recursive subtasks 8-10 levels deep), benchmark your FetchXML hierarchy queries with realistic data volumes before committing to the design. A depth of 10 on a table with 100,000 rows can produce noticeably slow queries.

---

Summary & Next Steps

You've now covered the full landscape of Dataverse hierarchical features. Here's the architecture in summary:

The self-referential hierarchical relationship is your foundation — one designated relationship on a table that creates the tree structure Dataverse understands natively. The hierarchical designation on that relationship unlocks everything else: efficient FetchXML operators, hierarchical rollup aggregation, and the hierarchy visualization control.

Hierarchical security (either Manager or Custom/Position model) layers access control on top of the data hierarchy by automatically propagating record visibility downward through a user hierarchy. It's powerful for organizational security models but has firm boundaries: user-owned records only, a maximum depth limit that must be configured correctly, and a delay before changes propagate to existing records.

Hierarchical rollup columns aggregate data across the entire subtree — not just direct children — giving you multi-level reporting without custom code. They're asynchronous and have a 10-level depth limit, so plan your user experience accordingly.

Hierarchy visualization in model-driven apps gives users an interactive tree browser. It's excellent for organizational navigation up to 1,500 records; beyond that or for conditional formatting requirements, a custom PCF control becomes necessary.

The most important design decisions are: which relationship gets the hierarchical designation (you only get one), which security model fits your org structure (Manager vs. Custom), and whether your security boundary is better served by business units, hierarchical security, or a combination.

For your next steps in this learning path, explore how your hierarchical data model interacts with the broader app experience. The data model decisions you've made here flow directly into how you design your forms — see Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms for how to surface hierarchical context on the record forms themselves. And when you're ready to go beyond the built-in visualization limits, Extending Model-Driven Apps with PCF Controls: Building and Deploying Custom Field and Dataset Components for Dataverse Forms and Views shows you how to build a fully custom tree component that can handle the scenarios the native control can't.