Hierarchical Relationships

Now that we understand Relationship Behaviours, let’s explore Hierarchical Relationships in this step.

You can gain valuable business insights by defining and querying hierarchically related data. The hierarchical modelling and visualisation capabilities give you a number of benefits:

• View and explore complex hierarchical information.

• Build and analyse aggregated information, e.g. key performance indicators (KPIs) or company turnover, in the contextual view of a hierarchy.

• Query hierarchical data for reporting and development purposes.

Some standard entities in Common Data Model already have hierarchies defined. Other entities, including custom entities, can be enabled for a hierarchy and you can create the visualisations for them.

The option to define a hierarchical relationship is only available for self-referential relationships. A self-referential relationship is a 1:N relationship between an entity and itself where the same entity is defined as both a primary and a related entity.

For example, Project within your organisation may have a number of sub-projects included, each with an independent set of data. By defining the self-referential relationship for the Project entity, you define a data structure where a project can have a parent project and sub-projects thus creating a hierarchy.

Once the relationship is defined, you can declare it as hierarchical by setting Hierarchical option to Yes using the relationship properties window in the classic solution explorer. The following limitations apply:

• Some of the out-of-the-box (1:N) relationships can’t be customised. This will prevent you from setting those relationships as hierarchical.

• You can have multiple self-referential relationships, but only one relationship per entity can be defined as the hierarchical relationship.

Once the hierarchical relationship is defined, and a record is part of the hierarchy, users will be able to select View Hierarchy option in the model-driven apps when the record is selected.

Hierarchy view uses Quick View forms that are part of the solution to visualise individual records. If more than one Quick View form is available, users will be able to switch using the form selector.

Creating a hierarchy adds new customisation capabilities:

• Create rollup fields utilising the hierarchy. For example, you can create a Total Budget rollup field for the Project entity that will include the sum of all budgets for all sub-projects under a record in the hierarchy.

• Build views and processes that query the data using Under/Not Under logic exposed in Advanced Find and the workflow editor.

Removing Hierarchy

Once you set Hierarchical property, rollup fields, processes and views can be configured to depend on this property. If you set Hierarchical option to No to remove hierarchy from the relationship, later on, those capabilities that depend on the hierarchy will not work.

Additional Considerations

Some of the out-of-box (1:N) relationships cannot be customised. They provide a specific behaviour and function in the application. Because of this fact, you are not able to set the relationship as hierarchical. A new self-referential relationship would need to be created and then defined as hierarchical.

Hierarchy and visualisation are limited to one entity only, e.g. you cannot show accounts and contacts in the same visualisation.

Next up, we focus on Other Entity Options.