Lists are the skeleton of every Anaplan model. Get them right and formulas stay short, dashboards stay fast, and imports stay boring. Get them wrong and you pay for it in sparse cell bloat, LOOKUP chains, and a model nobody wants to touch. This tutorial walks through the list-design decisions that matter most: flat versus hierarchical lists, numbered lists, subsets, line item subsets, and composite hierarchies.
1. Start with the question each list answers
Before creating a list, write down what it represents and how it will change. A useful test: is this a dimension you analyze by (Region, Product, Cost Center), or an entity you transact on (Invoice, Requisition, Opportunity)? Dimensions are usually small, stable and hierarchical. Transaction entities are large, change often, and rarely need to be a dimension of every module.
Two rules of thumb:
- Never put a transaction-level list in a module dimension if a summarized version will serve the report.
- Never use a list when a line item will do. Attributes such as status or currency code belong on a list as properties, not as separate lists, unless you need to dimension by them.
2. Flat, hierarchical, or numbered
Flat lists suit small reference sets (Scenario types, Approval statuses). Keep them as plain lists and set the display name property.
Hierarchical lists use parent-child relationships, with a parent property that points at another list. Build them as one list per level (Region → Country → Site), with each level carrying a property that references its parent. This is easier to maintain, and it gives you a clean target for SUM with a mapping (SUM: Site Mapping).
Numbered lists carry an automatic index. Use them for large, record-like lists where the code is not guaranteed unique or stable (transactions, journal lines). They allow you to import without needing a clean unique key, and they support Parent hierarchy loading via a key column.
Practical advice: use numbered lists only when you must. Code-based lists make merges and reconciliation far easier, because the code is the key.
3. Build a naturally ragged hierarchy
Ragged hierarchies (an org chart where some branches are deeper than others) are the classic trap. Instead of forcing every branch to the same depth, use a single hierarchical list with parents and then expose level views with a Level line item calculated by PARENT() counts. Alternative: model one list and use the ISANCESTOR and PARENT functions to build reporting levels:
Level 1 = IF ISANCESTOR(Org.Root, Org) THEN ...
Keep the ragged logic in one module, and have every other module reference it by mapping. That way a restructure is a data change in one place.
4. Subsets
A subset is a view of a master list that picks which members apply to a module. Use subsets when a module should only see part of a list, such as "Active Products" or "Capex-eligible Cost Centers". Benefits:
- Smaller dimensions in modules, which means less memory and faster calculation.
- Controlled membership: the Boolean flag drives inclusion.
Pitfalls: a subset only works if you maintain the flag. Drive the flag from a data module and use an action to refresh the subset, rather than editing it by hand. Document the owner.
5. Line item subsets
A line item subset is a dimension made from the line items of a module. It is the cleanest way to run one formula pattern across many measures, such as a Financial Statement line list.
Use it to:
- Build a statement module where rows are line items (Revenue, COGS, Opex) and the columns are time.
- Drive formatting and sign conventions from a single mapping.
- Replace dozens of near-identical modules with one.
Take care: line item subsets are tied to the source module. If you reorder or rename line items, dependent modules change. Treat the source module as a controlled object, and lock it down with selective access.
6. Composite hierarchies
When you need to report on a combination of two lists (Product × Region) as a single dimension, a composite hierarchy is the tool. It avoids creating an enormous sparse module by building only the combinations that exist. Load it from a data module with the two dimension keys; the combination list is then available for modules and dashboards.
Use composites when the combination set is much smaller than the full cross product. If more than about 20 to 30 percent of combinations exist, plain dimensions are usually simpler.
7. Performance checks
Run this checklist before sign-off:
- Dimension size: no module should have a dimension combination wildly larger than needed. Check module size in the model's Settings.
- Sparsity: sparse data across big dimensions is where memory goes. Reduce with subsets or composites.
- Formula references: replace
LOOKUPon large lists withSUMand mapping modules where practical. - Naming: consistent code and name patterns, so imports can match on either.
8. Importing lists safely
- Use a dedicated import module with a clean saved view.
- Always load the parent list before the child.
- Set Create new members only on the import actions that own the list.
- Add a dashboard-visible error check: any imported row that fails mapping should appear in a Rejected rows module.
9. Governance
List structure changes ripple through every dependent module, so route them through your release process. Use a dev-to-prod revision with a short description for each structural change, and test against representative data before syncing.
Summary
Choose the simplest structure that answers the reporting question: flat for reference data, hierarchical with parent properties for dimensions, numbered only when you lack a stable key, subsets for scope, line item subsets for statement-style modules, and composites for sparse combinations. Models built this way are smaller, faster, and far easier to hand over.
If you want an experienced Anaplan architect to review your list design or untangle a bloated model, get in touch.