In multiple Anaplan implementations across FP&A, S&OP, and operational planning use cases, a recurring design challenge is the overuse of hierarchical lists with Top Levels, especially on large transactional or operational lists.
In many projects, hierarchies are introduced early with the intention of providing “future flexibility” for reporting or aggregation. For example:
- Customer lists with an “All Customers” Top Level
- Product lists with Category — Sub-Category—All Products
- Cost center or entity lists with roll-ups that are never actively used
While the intention is good, in practice these Top Levels often:
- Do not serve any active reporting or decision-making purpose
- Are not used on dashboards by business users
- Exist purely because they were added “just in case”
Despite this, once a hierarchical list is used as a dimension in calculation modules:
- Aggregations are calculated at every parent level
- Model size increases unnecessarily
- Recalculation time and imports become slower
Over time, this creates performance issues and makes the model harder to maintain or refactor. Removing the Top Level later becomes risky because it touches multiple modules, dashboards, saved views, and potentially security or integrations.
As a workaround, experienced model builders often:
- Rebuild calculation modules at the lowest grain
- Create separate reporting modules for summary views
- Replace Top Level aggregations with Boolean-based filters (e.g., Is Active)
- Avoid using the hierarchical list as a dimension where roll-ups are not required
However, these workarounds rely heavily on experience and discipline, and there is no strong in-platform guidance or guardrail to help builders avoid this design trap early in the model lifecycle.
How often is this impacting your users?
This issue occurs very frequently, especially:
- During initial model design phases
- In fast-paced implementations with tight timelines
- When models are built by less experienced teams or handed over between partners
In practice, this impacts:
- Almost every medium-to-large Anaplan model at some point
- Models that grow organically over time without architectural reviews
The performance and maintainability impact often becomes visible months after go-live, making it harder and more expensive to fix.
Who is this impacting?
This issue impacts multiple roles across the Anaplan ecosystem:
- Model Builders – Increased complexity, slower recalculations, harder troubleshooting
- Solution Architects – Forced to refactor designs and justify architectural changes later
- Partners & Implementation Teams – Technical debt accumulating across projects
- Admins – Larger model sizes, space constraints, longer sync times
- Business Users & Planners – Slower dashboards and unnecessary summary views
- Executive-level Users – Delayed insights due to performance degradation
What would be the ideal solution? How would it add value to your current experience?
The ideal solution would help guide and reinforce intentional hierarchy design early in the modeling process, rather than correcting it after performance issues arise.
Potential improvements could include:
- Clear platform guidance or design warnings when adding Top Levels to large lists
- Best-practice recommendations surfaced during list or module creation
- Educational prompts encouraging builders to justify the business purpose of a hierarchy
- Stronger differentiation between calculation-grade lists and reporting-only hierarchies
This would add value by:
- Reducing unnecessary model complexity
- Improving performance and scalability from day one
- Lowering long-term maintenance and refactoring effort
- Helping less experienced builders adopt architect-level thinking
- Enabling teams to build leaner, more intentional Anaplan models
Ultimately, this would lead to faster, more scalable, and more sustainable models, benefiting both technical teams and business users.
~Bhumit
