Balanced vs. unbalanced hierarchies
One of the foundational elements of any Anaplan model is hierarchical lists. When creating hierarchies there are two basic choices: balanced or unbalanced. In this article, we'll look at the differences between balanced and unbalanced hierarchies, areas where they behave differently in Anaplan, and some questions to consider when trying to choose which one to use in a particular situation.
Definitions
An unbalanced (aka ragged) hierarchy is one in which the leaf levels (lowest level of detail) does not have a uniform number of ancestors across the hierarchy. A common example of this is a GL chart of accounts.
A balanced hierarchy is one where all the leaf levels have the same number of ancestors across the hierarchy, and in general, all the members at a given level have a similar concept associated with them. A common example is an organizational structure.
In the examples above, the lowest level in the account hierarchy (GL accounts) exists at both level 4 and level 5—making this an unbalanced hierarchy, whereas, in the organizational hierarchy, the lowest level (cost centers) is uniformly at level 3 and is, therefore, a balanced hierarchy.
Differences in setup
Unbalanced hierarchies are generally set up as a single list in Anaplan. This configuration is referred to as a parent-child hierarchy. The relationship of a list member to its parent is configured through the Parent attribute in the list where the parent is another member of the same list.
Balanced hierarchies are set up using two or more separate lists with their relationships defined using the Parent Hierarchy attribute in the General Lists settings. This configuration is referred to as a composite hierarchy. The relationship of a list member to its parent is configured through the Parent attribute in the list where the parent is a member in its parent list.
Differences in behavior
Anaplan holds data at the leaf level of a list only. Parent levels are calculated when the data is requested by a grid rendering or when an export action is run. A parent-child list only has a single leaf level, whereas, in a composite list hierarchy each of the individual lists has its own leaf-level even though the upper-level lists leaf-level may be calculated values. Because of this distinction, there are differences in how these hierarchy constructs behave in Anaplan.
Parent level input
Data input (entered or imported) can only occur at the leaf level of a list. In a parent-child hierarchy, there is only one leaf level and therefore only one point data can be input. Because each individual list has a leaf level in a composite hierarchy, data can be input at any level of the hierarchy by using the desired input list in a module.
Lookup() vs. select() behavior
The Anaplan Lookup() and Select() functions both are used to return values from a specific member from another member in the model but in different ways. Lookup() takes a time period or list formatted line item as its mapping parameter, while Select() takes a time period or an individual member of a list as the location of the source data. The other major difference is Lookup() can only take stored values from leaf levels while Select() can access any level of a hierarchy. Because of this difference Select() will work with either type of hierarchy but Lookup() will only work with a composite hierarchy.
Because Select() is a hard-coded reference to a list member, its use is not considered a best practice. If Select() is used to any list member other than a virtual top-member the list cannot be set as production data. Refer to the Planual section 2.02-14 for more details on the proper usage of the Select() function.
Unbalanced Hierarchy
Balanced Hierarchy
Enabling/disabling specific levels
In a parent-child list, there are only two levels: summary (all parent levels) and detail (all leaf members) so you cannot selectively enable/disable a specific parent level. However, this can be achieved using filtering. In a composite hierarchy, members exist in distinct levels (lists) they can be individually displayed or suppressed.
List Members
In an unbalanced hierarchy, only the actual members that exist in the source system are needed. In a balanced hierarchy, all members of each level must exist in the same list so if some members don’t have a particular level, then balancing (aka dummy) members must be created as placeholders in the list that is missing a member
In the example, the ‘Elimination CC’ is used across all BU’s in the Division, so it does not have a real BU but in order to allow data entry in this CC in a module along with other CC’s, it would need to have a dummy BU created to ‘push’ it down to the same level as other CC’s.
The Elimination CC could exist at the BU level and still have data input by using the Business Unit L2 list in a module if it did not need to be in the same input module as the other cost centers.
Summary of Functional Differences
| Functionality | Unbalanced Hierarchy | Balanced Hierarchy |
| Data input at parent levels | Not possible. | Inputs can be made at the leaf member in any of the lists in the hierarchy. |
| Select() function | Will return a value from any member in the hierarchy. It will limit the ability to set the list as production data or clear the list member(s) that are referenced in the Select() function. | Will return a value from any member in the hierarchy. It will limit the ability to set the list as production data or clear the list member(s) that are referenced in the Select() function. |
| Lookup() function | Will only be able to return a value from the leaf members in the hierarchy. This can be worked around with mapping modules but requires additional setup and maintenance. | Will be able to return values at all levels of the hierarchy because each list has a leaf level with values either input or derived. |
| Levels in selectors and modules | In a parent-child list, there are only two levels: summary (all parent levels) and detail (all leaf members) so selectively enable/disable specific parent levels cannot be done. This can be achieved using filtering. | Because member exist in distinct levels (lists) they can be individually displayed or suppressed. |
| List members | The list would only have actual members that exist in the real business structure. This makes navigation and reporting cleaner and simpler. | If the actual business structure is not completely balanced across the hierarchy dummy members will have to be added to give proper balancing. This increases the size of the lists which can impact memory usage and performance. Also depending on the number of dummy members that must be added, the navigation and reporting may be cumbersome. |
Conclusions and considerations
No one choice is correct in all situations. Different models and different lists need to be evaluated individually based on the use case to decide which structure is correct to use. As a general rule, a chart of accounts should be kept as an unbalanced hierarchy and any other hierarchy should be balanced, but some factors to consider are:
- Is there a requirement to input at parent levels of the hierarchy? If so, a composite hierarchy is required.
- Is there a requirement to have a line item dynamicallyreference values from different parent members within the hierarchy? If so, Lookup() is the correct choice which will require a composite hierarchy.
- Are calculations that need to reference parent level values limited or is the only parent to be referenced the virtual Top Member in the hierarchy. Then the Select() function is a reasonable option allowing for either type of hierarchy can be used. References to actual list members is not the best practice in either type of hierarchy.
- Is the actual hierarchy data extremely unbalanced? If so, then the maintenance and performance impact of creating the dummy balancing members should be evaluated. Also, consideration of how the user experience could be impacted when navigating the hierarchy.
Selecting the correct hierarchy type for a given use case is important to build efficient models and a good user experience. In general, charts of accounts should be held as unbalanced hierarchies and other types of hierarchies should be balanced but a careful evaluation of the use case and impact to design is important.