Save your model structure for personalized formula recommendations
Define your model's structure to get personalized formula suggestions across all tools.
Every Anaplan model is unique. The lists you use, the naming conventions your team follows, the dimensions applied to your key modules — these are the details that turn a generic formula into one that works in your specific model. The Model Context Manager exists to capture these details once and apply them everywhere, so you spend less time re-explaining your model and more time building it.
Good model documentation captures the key structural elements that any model builder or auditor would need to understand to work effectively in the model. This includes:
Core lists: The main lists in your model — Products, Customers, Employees, Cost Centers, etc. Include list sizes (approximate member counts) and whether lists have hierarchies.
Module architecture: Which modules exist, what dimensions each has, and what category of data they hold (input, calculation, reporting, system).
Naming conventions: The prefix conventions used for line items and modules, so formulas and references use the correct naming pattern.
Key line items: Names and formats of frequently-referenced line items — especially lookup keys, flag line items, and summary totals that appear in many formulas.
Many organizations maintain formal model documentation — typically a Word document or Confluence page describing the model architecture. Model context as captured here is complementary, not a replacement. While formal documentation goes deep on business rules and data flow, model context captures the quick-reference structural facts you need when writing formulas day-to-day.
Think of it as the difference between a city's zoning map (comprehensive documentation) and a personal notes card you keep at your desk with the addresses you visit every day. Both are useful; the notes card is faster to use in the moment.
Separate concerns by module type: Keep input, calculation, and reporting modules separate. Input modules should contain only manually entered data. Calculation modules should contain only derived values. Never mix the two — it makes auditing much harder.
Use a Settings module: All business rules, rates, percentages, and thresholds should live in a dedicated Settings or Parameters module. This creates a single source of truth for assumption changes and makes the model easier to update.
Minimize cross-model lookups: References that span models are slower than references within the same model. Design your model so that frequently-used lookups stay within model boundaries where possible.
Document your time scale: Record which time scale each module uses — Days, Weeks, Months, Quarters. Mismatches between module time scales are a common source of aggregation errors.
There's no universal answer, but a focused planning model typically has 20–60 modules. Models with hundreds of modules often indicate fragmentation that could be consolidated. Models with only a handful of modules often have modules that are doing too much, making them hard to maintain and slow to calculate.
Hub-and-spoke (also called star schema in database design) is a model architecture where a central "hub" module contains the key data, and "spoke" modules handle specific views or calculations for different functional areas. This design reduces duplication, makes updates easier, and is widely recommended for enterprise Anaplan deployments.
Best practice is to provide: a module inventory listing every module with its purpose and dimensions, a list inventory describing all lists and their sizes, the naming conventions used, a data flow diagram showing how data moves between modules, and any known quirks or workarounds. The Model Context Manager helps capture the structural elements — combine it with a written data flow narrative for a complete handoff package.