1. Architectural Design & Migration (Classic vs. Polaris)
Guidance on when to use Polaris, key modeling shifts, and migration strategies.
When to migrate / Choose Polaris:
Question: Should new builders learn Classic or Polaris? When does migrating make sense?
Answer: If you are entitled to Polaris, start there. However, since many environments use a hybrid strategy, understanding both is important. Migrate existing Classic models only if Polaris solves a specific scale/sparsity problem Classic cannot.
Modeling Anti-Patterns:
Question: What is the biggest anti-pattern when migrating Classic models to Polaris?
Answer: Classic models are often designed to minimize size by concatenating dimensions. In Polaris, it is a major anti-pattern; you should separate these into distinct dimensions to let the sparse calculation engine work naturally.
Migration Resources:
Question: Do we need to completely rebuild models to migrate to Polaris?
Answer: Migration is a massive topic. Anaplan has published a comprehensive step-by-step guide in the Polaris Best Practices section of the Anaplan Community.
Community Article
Dimension Limits (DIT/2^64 limit):
Question: What should we do if adding the full production list in the Test environment pushes a line item over the $2^{64}$ limit?
Answer: This must be evaluated during the initial architecture/design phase. Guardrails like subsets and time ranges must be designed upfront to avoid hitting physical platform limits.
2. Performance, Sparsity, & Formula Optimization
How does the Polaris engine calculates, and best practices for writing high-performance formulas.
Sparsity & Cell Count Ceilings:
Question: Is there a maximum cell count or dimension ceiling for sparse modules to maintain performance?
Answer: No. Performance is not driven solely by sparsity; it depends on formula structure, summary methods, and the overall shape of the data.
LOOKUP and PREVIOUS Performance:
Question: How do LOOKUP and PREVIOUS perform in sparse modules? Are there alternatives?
Answer: These functions (especially LOOKUP) can scale slowly at a massive scale because the engine has to search the indexes of populated cells. Use them with caution and test thoroughly. Use SUM where possible, although it is not a direct replacement for LOOKUP. PREVIOUS performs well, so no alternative is needed.
Community Article.
Planual Rule: 2.02-34 Prioritize SUM over LOOKUP
Guarding Formulas with IF THEN:
Question: How do we avoid nested IF statements to guard against "All Cells" calculation? Does nesting degrade performance?
Answer: Use IF statements to guard formulas. In Polaris, nesting IF statements matters less because the engine is highly efficient at finding the fastest path through the logical tree. However, excessively long nested chains in very high cell-count line items can still impact performance. Keep formulas as simple as possible.
Planual Rule: 2.02-36 Use IF THEN statements as guards in formulas
Logical Test Order (IF NOT A vs. IF A):
Question: Is it faster to test for cases we want to calculate, or cases we do not want to calculate?
Answer: The syntax order does not matter to the engine (IF NOT A THEN B ELSE C performs identically to IF A THEN C ELSE B). The goal is simply to write logic that preserves sparsity by keeping the total number of populated cells to a minimum.
Planual Rule: 2.02-26 Early Exits in Polaris don’t matter as much as they do in Classic
Sparsity Breakdown & Empty Cells:
Question: Why does performance degrade on very large dimensions even when highly sparse? Does the engine still iterate over empty cells?
Answer: Polaris naturally ignores empty cells. However, if your formula or logic explicitly instructs the engine to look at zeroes, blanks, or FALSE values, you inadvertently "reverse" sparsity and force the engine to calculate those intersections.
3. ALM, Developer Environments, & Data Loads
Strategies for managing Application Lifecycle Management (ALM) and handling heavy data updates.
Three-Tier ALM Setup Value (Dev vs. Test):
Question: Why maintain smaller, stripped-down lists in Dev if we have to test against full datasets anyway?
Answer: This separates syntax/logic validation (done quickly in Dev to maintain model builder productivity) from performance/scale validation (done in Test with millions or billions of cells).
Community Article.
Planual Rule: 6.05-06 Always use Iterative Development with Polaris
Multi-Builder Coordination:
Question: Should concurrent model builders share a single Test model or have their own?
Answer: A single, shared Test environment is sufficient, provided you coordinate development and code pushes using the Anaplan Way or another structured methodology.
Handling Large List Updates:
Question: What is the best way to handle large data loads to a list used in many calculations?
Answer: List updates trigger recalculations across all dependent line items. Be highly intentional with timing: consolidate all list updates, code updates, and subset changes into a single action so the model only has to recalculate once.
Planual Rule: 1.05-14 Update Lists with a single action
Slowing ALM Syncs:
Question: How do we prevent ALM syncs from taking hours when calculations are complex and data is bulky?
Answer: Practice iterative development. Push structural changes in smaller, focused packages (by user story or module) rather than saving up massive releases. This prevents the engine from bottlenecking during a single massive compilation.
4. Model Management, Monitoring, & On-Demand Calculation
How to read calculation metrics and manage real-time engine behavior.
Calculation Effort %:
Question: Is Calculation Effort % a static measure of the whole model? Does it change with user activity?
Answer: No, it is dynamic. It measures CPU time spent on calculations. Immediately following a model restart, it reflects the line items contributing to model open time. During active use, it dynamically updates based on the last 10 minutes of user entries, imports, and dashboard interactions.
On-Demand Calculation (ODC) Dynamics:
Question: What happens when multiple users trigger On-Demand Calculations simultaneously?
Answer: The engine calculates it for the model; once calculated for one, it is available for all users.
Community Article.
Dev vs. Copy Cell Count Differences:
Question: Why does the populated cell count sometimes differ between an active Dev model and a fresh copy of it?
Answer: This is typically driven by temporary on-demand cells populated in the active model that are not saved in the structural copy.
5. View Optimization, Imports, & Exports
Best practices for moving data and designing user-facing grids.
Saved Views for Hub-and-Spoke Data Transfers:
Question: How do we optimize saved views between Polaris spoke models to prevent slow loading times?
Answer: Avoid nesting multiple large dimensions on the rows of pivoted export grids. Instead, pivot the view to show a single flat list on the rows and filter it using a single Boolean line item (e.g., Is Populated? = TRUE). Let the target Spoke import map and parse those dimensions upon ingestion.
Default Views & Open Times:
Question: Should default views have hidden levels to reduce model open times?
Answer: Yes. Default views should be set at the leaf level only to prevent triggering heavy On-Demand Calculations upon opening.
Planual Rule: 2.04-03 Keep the Default View clean
