Best Of
Running IRR (IRR Calculation by Period)
In as much detail as possible, describe the problem or experience related to your idea. Please provide the context of what you were trying to do and include specific examples or workarounds:
The IRR function in Anaplan is calculating the final IRR based on the entire cashflow over the timescale. We need it to calculate it by period to get the IRR value by period.
How often is this impacting your users?
Very often as it is blocking their planning & forecasting. Creating a manual workaround for this is size heavy (each report taking around 60-70 GB) as the calculation is happening by day.
Who is this impacting? (ex. model builders, solution architects, partners, admins, integration experts, business/end users, executive-level business users)
Business/end users, solution architects (for replicating this manually)
What would your ideal solution be? How would it add value to your current experience?
IRR function allowing to define the start and end period and to calculate it over time period.
Please include any images to help illustrate your experience.
hareeshm
Re: Question 6 in level 1 model building exam
Also another hint. You're very, very close.
Use the SUM function on Region and Role from your SYS08 module.
Breakdown:
- YOu need Medical costs from EMP02 which uses Employee as a dimension but your TARGET module, REP04 is dimensioned using Region and Role.
- So you need to convert your employee dimension to region and role. Your SYS08 does this!
- Remember, you always use SUM on a list formatted line item.
- So your formula will look something like this. EMP02.Medical Costs[SUM: SYS08.Region, SUM: SYS08.Role]
You got this!
Summary behavior W.r.t Selective Access
In as much detail as possible, describe the problem or experience related to your idea. Please provide the context of what you were trying to do and include specific examples or workarounds:
in the current state, when Selective Access is enabled on hierarchical lists, users are restricted to viewing only the list members they have been granted access to. While this works well for controlling leaf-level visibility, it also impacts how summary values (parent-level totals) are calculated and displayed.
Specifically:
Users can only see data for the leaf items they have access to.
Parent-level totals (summaries) are not appropriately displayed as per the access.
This results in incomplete or misleading aggregates at higher levels of the hierarchy, which creates challenges for reporting and analysis.
In the current state only workaround seems to be adding User dimension to the modules, but this increases the size astronomically.
How often is this impacting your users?
This behavior is consistently observed in models where selective access is applied to hierarchical dimensions used for reporting which impact a lot of important reports
Who is this impacting? (ex. model builders, solution architects, partners, admins, integration experts, business/end users, executive-level business users)
Business/end users consuming summarized reports, Model builders and solution architects, Workspace administrators managing access and reporting
What would your ideal solution be? How would it add value to your current experience?
Introduce a configurable option to decouple summary calculations from selective access, such as:
A setting that enables “secure leaf access with appropriate parent aggregation”
Please include any images to help illustrate your experience.
Export configuration
When I export a module with a layout: Grid, all Pages,
I get 1 excel sheet per item from my list in page which is the result I want,
My only issue is that the excel tab is generic whereas I would need it to have the name of the item in the page,
Is it Something that could evolve?
cbenoit
Anaplan Polaris — Tips & Tricks
This article is part of a series on Polaris best practices. Click here for more Community content or visit Anapedia for detailed technical guidance.
Here at Anaplan, we're always looking for ways to help you get the most out of our platform. We know that sometimes the smallest adjustments can make the biggest difference in your modeling and planning processes. That's why we're excited to announce a new regular series: Polaris Tips & Tricks!
What to expect
On a regular basis, we’ll be sharing a new tip as a "feature" right here in the Anaplan Community. These bite-sized insights will cover a wide range of topics, focused on the Polaris calculation engine.
A growing resource
To make it easy for you to find what you're looking for, we'll be collating all the tips into this single, comprehensive article that you can refer to anytime.
We're kicking things off today with our first tip! Stay tuned and get ready to take your Anaplan skills to the next level!
Polaris tips and tricks
Look for our tips on the Community homepage, Resources, and Best Practices sections:
- With On-Demand Calculation (ODC), selecting a top-level aggregation calculates only that specific value via the most efficient path, skipping unnecessary intermediate levels...it will not calculate all the aggregations in between.
- In Polaris shifting functions such as POST, PREVIOUS, NEXT, OFFSET, LEAD, LAG and MOVINGSUM can be used over any dimension, not just time.
- More coming soon!
AnaplanOEG
Model Map - Export Model Schema
As a model builder, I need Anaplan Model Map to be able to export everything shown in the Model Map (model schema),
So that it will save me time to record Model Map status at different stages of the models for documentation purposes.
DingZ
Request to Display Comma-Separated Amounts on the Chart Axis
[Current Issue]
The chart below shows the result when Chart → Axis → Label Format = Manual is applied to the vertical axis (see Note 1).
In this case, the amounts on the chart’s vertical axis are not displayed with comma separators, which makes them difficult for clients to read and confirm.
Amounts displayed on the chart axis
Note 1: Details of the chart axis settings
[Requested Enhancement]
When Chart → Axis → Label Format = Manual is applied to the vertical axis (see Note 1), we would like the amounts on the chart’s vertical axis to be displayed with comma separators.
kyomori
Bubble Chart: Please always display all label names even when bubbles overlap
[Current Issue]
Currently, when bubbles overlap in a bubble chart, the label name of one of the overlapping bubbles is not displayed.
For example, as shown below, the blue bubble and the light blue bubble overlap.
The label name for the blue bubble is Name A, and the label name for the light blue bubble is Name B.
At present, only Name A is displayed for the blue bubble, while no label is shown for the light blue bubble.
[Enhancement Request]
Even when bubbles overlap, I would like all label names to be displayed outside the bubbles, as shown in the image below.
kyomori
Show all data labels in graph
In the NUX, line chart will not show data labels that are within 0.5% of each other or bar graphs that are within 3% of each other. This is a big issue for reporting purposes in the apps as it's hard to compare various KPIs and metrics to each other in the same period. This primary affects business/end users. We need a solution to show all data labels/fit all data labels into the graphs.
See Feb 25. Missing data label for the blue line and the green bar.
ltalston
CoE guidance: A practical Polaris migration strategy by project phase
Author: Laiza Tagumpay is a Certified Master Anaplanner with a background in Customer Success and Solution Architecture, now happily building and scaling Anaplan as a CoE Principal Engineer in a biotech company.
Migrating from Classic to Polaris is not a lift-and-shift exercise. It requires a mindset shift in how models are designed, built, tested, and governed.
This article outlines a phase-based Polaris migration strategy to help guide organizations through their Polaris migration journey.
Phase 1: Pre-migration strategy
Goal: Confirm Polaris suitability and prepare the team before any build begins.
- Assess Polaris suitability - Validate the model against Classic → Polaris migration criteria:
- Large modules with >~70% Sparsity
- Modules approaching Classic cell count limit
- Concatenated lists for dimensional workarounds
- Performance degradation in large modules
- Need access to new or AI-powered features
- Large modules with >~70% Sparsity
- Request a MAPS report from Anaplan CSBP — To identify other areas that are memory-heavy and high-effort calculations.
- Ensure team readiness
- All team members understand what to expect in a Polaris migration.
- Developers (MBs and SAs) complete all required Polaris training and read key articles.
- All team members understand what to expect in a Polaris migration.
- Capture baseline metrics and performance
- Model open time, import/export duration, populated cell count, model size.
- Model open time, import/export duration, populated cell count, model size.
- Align dependencies early
- Coordinate with Data Hub and other teams that integrate with or depend on the model.
- Coordinate with Data Hub and other teams that integrate with or depend on the model.
Outcome: Clear go/no-go decision, informed team, and known risk areas.
Phase 2: Design strategy
Goal: Redesign the model for Polaris — not as a Classic replica.
- Redesign don’t lift and shift: Re-evaluate structure through a Polaris lens.
- Apply Polaris best practices early; avoid deferring foundational design decisions.
- Limit scope: Defer major functional enhancements until post-migration.
- Design with natural dimensionality: Avoid transaction lists, concatenated lists, and flat staging modules.
- Use SYS helper modules
- Valid Combination modules driven by import boolean flags.
- Calculation Master Switch module to control expensive logic during data loads/testing.
- Valid Combination modules driven by import boolean flags.
- Schedule design reviews for critical components.
Outcome: A Polaris-ready design that preserves sparsity and performance.
Phase 3: Build strategy
Goal: Build iteratively with continuous performance visibility.
- Build in small, testable increments to reduce rework.
- Keep DEV lean: Use small list sizes in DEV, but ensure all lists and subsets are represented (even with just one or a few members).
- Continuously monitor Polaris Blueprint Insights in DEV environment: Export Line Items within 10 minutes of model open.
- Populated cell count
- Calculation effort
- Calculation complexity
- Populated cell count
- Refactor early: Address rising effort/complexity immediately.
- Maintain modeling hygiene: Remove unused lists, modules, line items, and actions to avoid unnecessary allocation of calculation effort.
- Connect to ALM early: Sync Dev → Test early.
- Create a revision tag per story and sync daily.
Outcome: Stable build with controlled performance characteristics.
Phase 4: Testing strategy
Goal: Validate real-world performance, behavior, and integrations.
- Continuously monitor Polaris Blueprint Insights in TEST environment too while gradually loading data to full list members and datasets.
- Re-export line items and refactor as needed.
- Validate end-to-end early.
Outcome: Confidence that the model performs at scale.
Phase 5: Deployment or release strategy
Goal: Transition safely without business disruption.
- Keep Classic active until Polaris is validated, approved, and stable.
- Create revision tags for each deployed function.
- Save model copies per sprint as part of release management.
Outcome: Controlled cutover with minimal risk.
Phase 6: Post-deployment strategy
Goal: Stabilize, optimize, and continuously improve.
- Monitor performance, integration health, and adoption.
- Track recalculation trends and usage patterns.
- Perform incremental refinements based on real usage.
- Introduce deferred enhancements gradually.
Outcome: A scalable, sustainable Polaris solution.
Closing takeaway
Successful Polaris migrations are less about perfect upfront design and more about making phase-appropriate decisions, monitoring performance continuously, and working closely with the Center of Excellence, Data Hub, and dependent team.
Questions or comments?
laiza