Author: Arun Thakar is a Certified Master Anaplanner and Vice President in the banking industry.
Lists and hierarchies are a key foundational aspect to model building. In Anaplan, lists are a critical building block of the model and depending on which structure one uses can greatly impact user experiences, model performance and architecture of a solution. This article is intended to help you, as an architect, to communicate the various types of lists and when they should be used for model builders, and end users.
There are several configuration options for lists in Anaplan, essentially you can create hierarchies in several different ways, let’s cover the main ones below.
Flat hierarchy
A single Anaplan list, can be named, or numbered. All levels of the hierarchy are present in one list with no parents in the list grid view menu, instead parent mapping is stored in a system metadata module.
A flat hierarchy has many uses in Anaplan models; the general idea is that these lists store all levels of the hierarchy and can be used to create saved views which build other hierarchies in the model. Using recursive lookups, a flat list’s system module can tie together all other hierarchies and generally modules dimensioned by flat lists are backend only. Good opportunity for creating list subsets for major levels.
Balanced, composite list, hierarchy
Multiple lists combined to form a hierarchy with parent lists configured in the general lists menu
.
A balance composite hierarchy has many uses in Anaplan models, the parent child relationship allows inputs to cascade, the ability to push down allocations and synchronize cards across a UX page. Enabling users to enter data at higher levels of the hierarchy makes the planning process simpler for end users. Also, the ability to synchronize cards across the UX is a key benefit of composite hierarchies. These hierarchies need to have the same number of levels for all branches and can sometimes cause issues for architecture who need to create dummy levels to balance the number of levels.
Ragged, single list, hierarchy
Single list wherein branches may end on different levels. For example, one branch of the hierarchy may end at level 7, while an adjacent branch may end at level 6. Creating and maintaining these lists is a little tricky. Parent-child relationships are managed within the list grid view menu. Must not be numbered.
This list is powerful but has tradeoffs in terms of technical debt. For many end users, seeing a ragged hierarchy is more intuitive than a hierarchy with dummy levels. For an architect there are multiple considerations associated with creating ragged single levels lists. Notably, if the list changes steadily over time, the list will need to be built one level at a time which will require multiple saved views. Also, stale node clearing is something that an architect should invest in for all their list maintenance. Selective access can be applied to any level of the ragged structure which makes this a powerful solution to creating better end user experiences.
Hybrid hierarchy
Broadly this can mean combining hierarchies together to enable planning, such as loading your workforce data as a child of the cost center hierarchy.
This concept can be helpful for applying selective access to data that is sensitive or needs to be entitled by parts of a hierarchy. The lowest level is its own list with the parent hierarchy configured in general lists. The bottom of this list only needs a mapping to the lowest level of the parent hierarchy. The example above of workforce as a child of cost center or concatenated summarized transaction lists are a couple examples of ways you can make hybrid lists work for your model.
Conclusion
There are dozens of combinations and permutations one can employ to create a hierarchy. When deciding on which archetype of hierarchy to employ, consider the purpose of what you are trying to accomplish. If a user is setting assumptions at a higher level, then perhaps a balanced composite hierarchy is the right solution. If your end users want to see intermediate aggregations and their hierarchy is ragged, then it may make sense to use a ragged, single list, structure.
