Planual rules regarding modules in the Polaris engine.
Note: Rule numbers on this page may not be sequential. Our Planual uses a common index across Classic Hyperblock and Polaris Engines, which means some rules only appear on one page or may have been removed.
2.01-05 Avoid using DISCO methodology to name functional areas
The DISCO convention is meant strictly for categorizing types of modules, not for organizing your overall model navigation. Because a single business process or functional area typically requires multiple types of modules (Data, Inputs, System, Calculations, and Outputs), organizing functional areas by DISCO limits logical flow. Always define functional areas by their specific business purpose (e.g., Revenue, Headcount, Expenses) rather than by their module type.
Engine Applicability: Classic Hyperblock and Polaris
relatedToRule
2.01-08 Create a system module for all key lists
| Create a system module for properties and attributes of key lists. Key lists include large lists, lists used in multiple modules, major hierarchies, or any list referenced frequently. All levels of a hierarchy should have their own system module. At a minimum, include the code and parent as line items. This allows for functions such as ITEM(), CODE(), NAME() to be calculated once for each member and referenced in multidimensional line items. Engine Applicability: Classic Hyperblock and Polaris |
exception
| 2.01-08a SYS Module isn't needed | If the hierarchy isn't referenced in a formula as a filter or a selector module on a dashboard then it isn't needed. |
bestPracticesArticles
2.01-09 Use Lookup or Constants modules
Create a module with no dimensions to hold assumptions for Time and other "SELECT" values. These are useful for global assumptions and general setting that are used throughout the model. They're also useful within an Application Lifecycle Management (ALM) setup.
relatedToRule
2.01-12 Group formulas with like dimensionality
| Create dedicated Calculation modules to house sets of line items that share the exact same dimensionality. Avoid creating subsidiary view line items, as grouping calculations with identical dimensions simplifies your model architecture, makes auditing easier, and optimizes engine performance. Engine Applicability: Classic Hyperblock and Polaris |
relatedToRule
bestPracticesArticles
2.01-21 Polaris: Model with natural dimensionality
You shouldn't have to create concatenated lists in Polaris. With that said, don’t create modules with every dimension, only use dimensions that are needed. Be aware of the end user and how they will interact with the module. Aim to create an overall user experience that will help them find specific data quickly and easily.
2.01-22 Polaris: Dimensional Order
Dimensional order in Polaris doesn't matter like it does in Classic.
