Visualize Complex Relationships with New Hierarchy Control

Last September I wrote an article introducing the new Hierarchy Control for model-driven apps and how it helps us better visualize relationships between self-referencing tables. In the article I explained how you can easily visualize data within a single table, for example parent and child accounts. It was a great start, but the control still had limitations because we could only use one single table in this control, but let’s face it, most business relationships rarely live neatly inside one single table. Think about it, accounts usually have contacts, opportunities, cases and more. You might even have created some custom tables to track information! With the latest update to the hierarchy control, we can now view multiple tables all in one visualization! This is a major step forward because it enables users to navigate data the same way relationships work in the real world. You can start at an account, drill down into associated contacts, explore linked opportunities and even expand into that custom table you created!

This new flexibility unlocks powerful scenarios. Imagine exploring large enterprise Accounts and instantly seeing all open Opportunities grouped beneath each division. Or mapping the structure of a partner network while still being able to drill directly into the Contacts who influence deals. Even industries like private equity or franchise management can now visualize complex tiers without needing multiple screens. Instead of jumping between views and forms, users can move through relationships visually and quickly get to the information they are looking for.

Configuration

Configuration is straightforward if you are already familiar with setting up the Hierarchy Control, but for you who are not I will walk you through the setup of creating a hierarchy using multiple tables. You can start the hierarchy creation process by navigating to the App Settings area in the Sales Hub in Dynamics 365 Sales. Click the ‘+New’ button on the command bar to create a new hierarchy record. Make sure to give it a name that explains the relationships that are represented in the view. For this example, I am going to create a hierarchy view that shows accounts and customer assets, contacts and their related work orders. The first table that is added here is the ‘root node’ of the hierarchy. This is the table/row that is the starting point of the hierarchy. To add the first table, click on the ‘Add Table’ tile on the screen and select the account table, then click add. You’ll notice the settings pane opens on the right side of the screen, where you can configure all the settings for the table you just selected. If you enable the ‘Expand all levels’ for a table and populate the parent ID column, you’ll see that any self-referencing child rows linked through that relationship (in this case it would show child-accounts related to the account we’re viewing the hierarchy for) will automatically show. I like this because this means I don’t have to manually add the self-referencing table like I did when creating a self-referencing hierarchy. Since I don’t want to show related child accounts, I disabled the ‘Expand all levels’ option in the account settings. I select the ‘Active Accounts’ view, as I don’t want to show inactive accounts in the hierarchy. I then select the tile form and the detail form.
The next step is to add the customer assets table. This represents all customer assets under the account. If you are not familiar with this table, this is a table in Field Service that represents assets that are related to a customer account. For example, the Contoso account could have an HVAC unit (customer asset) that has several parts that are stored as child-assets like surge protectors, a fan motor, etc. To add the table, click the ‘+’ button below the account tile and enter ‘Customer Assets’ as the table name. I select the ‘msdyn_account’ column under ‘Choose parent-child relationship’. Since I want to show the child asset for each customer asset I enable the ‘Expand all levels’ setting and set the self-referencing parent ID column (msdyn_parentasset) for the asset table. I select the ‘Active Customer Assets’ view and select the forms I want the hierarchy to use.

I also want to show account contacts in this hierarchy and the work orders related to each contact. To add the contact table, we need to click the ‘+’ button again (below the top tile) and select the ‘Contacts’ table. I select the ‘parentcustomerid’ column (which is a lookup field on the contact table) and since I don’t want to show any self-referencing relationships (child-contacts related to the contacts)for this table, I disable the ‘Expand all levels’ setting. Lastly, I select the tile and detail forms for the contact table.
As mentioned before, I want to show work orders related to each contact. The work order table has a lookup column to the contact table called ‘msdyn_reportedbycontact’ which is the relationship I am going to use to display the contact-related work orders. After clicking the ‘+’ button below the contact tile, I select the work orders table. I set the parent-child relationship to ‘msdyn_reportedbycontact’ and I leave the ‘Expand all levels’ setting disabled since I don’t want to view child-work orders for each work order. I select the appropriate view and forms and save the hierarchy. NOTE: You can change the display name of the table if needed.

Manual many-to-many relationships

What I really like about this new hierarchy control is that we can also show more complex relationships, for example these that are stored in manual many-to-many tables. These types of tables act as an intersect table and are used to link two other tables together. This is great because that means that the (other) tables don’t need to have a direct relationship to each other and allows for more complex visualizations. A good example of an out of the box intersect table is the connections table, but we can also show custom intersect tables in the hierarchy control, for example you could create a table that tracks events and an intersect table to track event registration. The event attendance table would have a lookup column to the contact table and the event table, representing the indirect relationship between the contact and event tables.

It is a bit more complicated to add a custom connections table like the one mentioned above, as we need to define the custom connections table and the relationships between the contact and the event tables. It’s also important to understand that there are several ways we can show this type of data in the hierarchy control. For example, if I only wanted to see the events a contact has signed up for, including details from the event (I.E event start date, event end date), we would not directly add the event registration intersection table to the hierarchy. Instead, we would add the ‘Events’ table (The intersect table is related to the events and contact table as shown in the image above,) and configure the relationship in the settings pane. To do this, you need to follow these steps: (You can create a new hierarchy control for the contact table or add it to the hierarchy control we created earlier). Under contacts, click ‘+’ and select the ‘Events’ table. Select ‘custom connections table’ under ‘Choose parent-child relationship’. The ‘Select custom connections table’ is where we need to select the intersect table, which in this case is the ‘Event Registrations’ table. For ‘Select relationship to table: Contact’ we choose the contact lookup column (in my case this is called ‘newregistrantcontact’) and for the ‘Select relationship to table: Event’ we need to select the event lookup column called ‘new_event’. Lastly we need to select a view and the forms to visualize the data.
If we prefer showing details from the event registration table instead, (I.E attendee type, registration date, etc.) we would add the ‘Event registrations’ table below the contact table and use the new_registrantcontact’ column as the parent-child relationship. Below is an image on what both configurations would look like to the end user.

Add connections

Adding connections to a hierarchy view is a bit different as there are different ways you can show the connections data. Option 1: Show a specific table that has connections to an account.
If you add connections to an account table and you only want to show a specific table the account is has connections for, you will not select the connections table (intersect table) but instead choose the table you want to see connections for, which in this example is contacts. We’;; need to add the contact table below the account table and choose ‘Dataverse connections table’ for the ‘Parent-child relationship’ field. To filter the results to only show contacts that are connected through a specific role, we could add roles in the ‘dataverse connection roles’ field. If we leave this field blank it will show all account/contact connections, regardless of connection role. The downside to this configuration is that we will not be able to view the connection role for the contacts with this setup.

Option 2: Show all connections for an account. If we needed to show all connections for an account regardless of which other table the connection is related to, we could add the connections table below the account. I did some testing with this and found that the best way to show the connections is to set ‘record1id’ under ‘Choose parent-child relationship’ as this will show the name of the row the account is connected to and the connection role, assuming you’re using the out of the box connections information form to show the data.

Preview Hierarchy

To preview the hierarchy that was just created, you will need to save it first. After the record is saved you can click ‘Preview’ to see what it looks like. If needed, you can change the way the data is shown, by clicking on the ‘Vertical (columns)’ button on the bottom left side of the screen. This allows you to change the visualization. It’s good to note that this is not a setting that will be saved when you publish the hierarchy record. Users can change the visualization after the hierarchy has been published. If there are multiple hierarchy records configured for a table, users can change the hierarchy by selecting a different record from the top of the screen.

From a user experience standpoint, this update feels natural and highly intuitive. Users can click to expand layers of related records and jump directly into details when something catches their eye. Multi-table hierarchy support is more than a visual enhancement. It is another step toward true relationship intelligence inside Dynamics 365. Users gain a clearer understanding of how everything is connected and the hierarchy becomes a living map of your customer landscape. If you have not explored this enhancement yet, now is the perfect time to experiment with it in your environment. Start with an existing hierarchy and add one or two more related tables to see what new insights you uncover. This improvement delivers real, immediate value and expands what is possible without custom code or additional apps. I am excited to see how everyone is going to us this. If you have a creative hierarchy scenario or want to brainstorm ideas, leave a comment or reach out. I always love seeing how Dynamics 365 helps users work smarter. I hope you enjoyed this article! Be sure to check in again soon or subscribe here to never miss another post!