Source Module Dimensions
Enter the dimensions (lists/time) of your source module:
Target Module Dimensions
Enter the dimensions of the module where you're referencing from:
Validate DISCO methodology - ensure same dimensionality
📐 DISCO Methodology: Dimension In - Same Calculation Out. Perform calculations over the same dimensionality to avoid performance issues and ensure accurate results.
Enter the dimensions (lists/time) of your source module:
Enter the dimensions of the module where you're referencing from:
Source Module: Product × Region × Month
Target Module: Product × Region × Month
✓ Perfect DISCO - Same dimensionality!
Source Module: Product × Month
Target Module: Product × Region × Month
✗ Different dimensions - Use LOOKUP or aggregate first!
Dimensionality is the most conceptually unique aspect of Anaplan for builders coming from Excel or SQL. Every module, line item, and formula exists within a specific dimensional context — and when dimensions don't match, formulas either fail or produce unexpected aggregations. The DISCO methodology provides a framework for thinking clearly about dimensionality in every formula you write.
DISCO stands for Dimensionality Is Same or Contains Only. It's a rule for validating whether a formula will work correctly based on the dimensional relationship between the target line item and the source line items it references.
The core principle: the source line item (what you're reading from) must have the same dimensions as the target line item (what you're writing to) — or the source can have fewer dimensions, in which case Anaplan will broadcast the value. If the source has more dimensions than the target, you need an explicit aggregation function (SUM, MAX, MIN, etc.).
When DISCO is violated — when the source has different dimensions than the target and no aggregation is specified — Anaplan will either throw an error or apply an implicit aggregation that may not be what you intended.
Same dimensionality — works directly:
Target: Revenue [Products × Time] = Source: Units Sold [Products × Time] × Price [Products × Time]
✅ All three line items share the same dimensions. No aggregation needed.
Source has fewer dimensions — broadcasting:
Target: Revenue [Products × Time] = Units Sold [Products × Time] × Price [Time only]
✅ Price broadcasts: each product gets the same price for each time period. This is valid DISCO.
Source has more dimensions — aggregation required:
Target: Total Revenue [Time only] = Revenue [Products × Time]
❌ Revenue has the Products dimension but the target doesn't. You must write: SUM(Revenue[LIST: Products])
"Formula reference is invalid": Most commonly caused by a dimension mismatch. Check whether the referenced line item has a dimension the target doesn't, and add the appropriate aggregation.
Unexpected totals in reports: If your aggregation is higher than expected, an implicit aggregation may be happening. Make all aggregations explicit with SUM, MAX, MIN, or COLLECT.
LOOKUP returning wrong values: LOOKUP requires the key dimension to match. If your LOOKUP key has a different dimension context than the referenced module, results will be wrong or blank.
Zero instead of blank: If a source value is blank and DISCO forces it into a different dimensional context, Anaplan may convert the blank to zero. Use explicit IF checks to preserve blank behavior where needed.
Lists are the data structures (e.g., Products, Regions, Employees). Dimensions are lists that have been applied as axes to a module. When you add a list to a module's blueprint as a dimension, every line item in that module gets a row (or column) for each member of that list. The module's size is the product of all its dimension member counts times its time periods.
Yes. Modules with many large dimensions grow exponentially in size. A module with 1,000 Products × 500 Customers × 24 time periods × 10 line items already contains 120 million cells. Best practice is to keep modules focused — 2 to 4 dimensions is typical for most well-designed modules.
Line item subsets allow you to add a module's own line items as a dimension to another module — making the line items themselves a list. This is a powerful technique for building flexible reporting modules and driver-based planning structures, but it adds complexity and should only be used when the business requirement genuinely calls for it.