Author: Dave Smith is a Senior Product Manager at Anaplan.
In the world of enterprise planning, working with hierarchical data is fundamental—whether you're dealing with product categories, organizational structures, or geographic regions, the ability to roll up and see your plans at a macro-level is essential. Until now, Anaplan users had to rely on workarounds using ratio summary methods to perform operations which relied on the level of an item in a hierarchy. This technique works well, but it introduces complexity to your model. That changes with two powerful new functions available in the Polaris Calculation Engine: ITEMLEVEL and HIERARCHYLEVEL.
The challenge: Managing hierarchical data
Planning professionals frequently need to:
- Display or filter data based on specific hierarchy levels
- Apply different calculations depending on where items sit in the hierarchy
- Create scalable solutions that adapt to changing organizational structures
Previously, achieving these goals in Anaplan required complex workarounds that were both performance-intensive and difficult to maintain.
Introducing native hierarchy functions
The new ITEMLEVEL and HIERARCHYLEVEL functions bring functionality to determine the level of items in a hierarchy natively to Polaris, offering:
- Simplified implementation: No more complex ratio summary workarounds
- Enhanced performance: Built-in functions execute more efficiently
- Greater flexibility: Operate on both cells and list items directly
- Future-proof design: Automatically adapts to hierarchy changes
ITEMLEVEL function
ITEMLEVEL determines the position of a given item within its list, measuring the distance from the item to either its root ancestor or its furthest leaf descendant. It operates on model data – a specific item in a list, or the item in each cell of a list-formatted line item.
Syntax: ITEMLEVEL(Item [, Direction])
This function is perfect when you need to work with specific items in your hierarchy and understand their relative position. For example if you wanted to determine the level of a specific list item such as Products.Item 1, or if you need to determine the level of a list-formatted line item.
HIERARCHYLEVEL function
HIERARCHYLEVEL determines the position of a cell’s related dimension, finding the distance to either the root ancestor or the furthest leaf descendant of list items within a given list. It operates on a list itself, rather than on the data within a model.
Syntax: HIERARCHYLEVEL(List [, Direction [, Level type]])
This function works great when you are working with module dimensions and you need to apply logic based on hierarchy depth. If you have a line item dimensioned by the ‘Products’ list, you can use HIERARCHYLEVEL(Products) to get the level of whatever item in the list is referenced by the current cell.
Step-by-step usage example
That’s a lot of theory — let’s dive into a simple example of how this can be used to power filtering in a way which was previously difficult to achieve. I have a simple module which lists all of my demand for a fictional fast-food franchise, Flaming Burgers:
This is a great overview, but it’s a lot of information. Nonetheless, my users want the flexibility to see this data at both a macro and micro level. Seeing aggregated data for the product level is easy enough, we can just use a context selector to allow selection of individual products and whole product categories — this is the native power of modeling hierarchies at their natural dimensionality in Anaplan. But it’s trickier on the time axis — it's useful to be able to select a specific time period and drill into it, but what if I want to see macro-level aggregated trends, for example to look across the whole timescale at the year or quarter level? This is now much more straightforward thanks to these functions.
First of all, let’s create a list for the levels of the hierarchy that we want to support filtering on. These can be named whatever you like but for simplicity I have named them after the different levels of the time hierarchy. We will also assign a code to each which corresponds to the level in the time hierarchy:
Next, we need to create a SYS module which simply turns these values into numbers which can be compared to the output of ITEMLEVEL. This is a simple module, without timescale, dimensioned only by the Time Levels list:
To get the number for the corresponding code, we just use a simple formula:
Now to use our new formulas, we will create a module which is dimensioned by time at the week level, and by the Time Levels list:
Now we can create the data to drive our filters. In this instance I’ve chosen to display the lowest level selected plus any summary levels. This is achieved with a Boolean line item, with the formula 'SYS10 - Time Levels'.Level >= HIERARCHYLEVEL(Time), and summary set to Formula. This gives me a ‘true’ value for each intersection where the time period matches the chosen time level or above, you can see the start of that grid here:
Now all that is left is to add a filter to our initial products view, which lets us pick the Time Level and filters out other levels accordingly. First we need to add the ‘Time Levels’ as a dimension.
Then we add a filter to use this to show or hide certain levels of the time hierarchy.
And now we can save the view, and use it on a UX page to use the filter:
Getting started
Both functions are exclusively available in the Polaris Calculation Engine, part of Anaplan's continued investment in next-generation planning capabilities. Whether you're building new models or enhancing existing ones, these functions offer an opportunity to simplify complex hierarchy logic while improving performance.
Ready to leverage these powerful new capabilities in your planning processes? Start by identifying areas in your current models where hierarchy-based logic could benefit from these native functions, and explore the new possibilities enabled by these new functions. Or take a look at your reporting views to see where this kind of filtering could help your users to better understand their planning data.
Questions? Leave a comment!
……………
View additional Polaris-related articles here.
