This page has Planual rules regarding Modules that only apply to Polaris, as well as shared rules with Classic Hyperblock (which are also on the Classic Hyperblock page). Check each rule’s applicability tag to see where it applies.
Rule numbers may skip, since Polaris and Classic Hyperblock share one numbering index.
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-06 Avoid using Subsidiary views
General Guidance: Subsidiary view line items are difficult to work with and audit. Try to minimize their use, especially for calculation modules. Instead, create groups of calculation modules with like dimensionality. When designing interfaces for display purposes, using Combined Grids on UX pages can provide a more efficient alternative. Polaris Specific Guidance: In the Polaris calculation engine, subsidiary views can cause performance degradation when used in model-to-model imports or export actions. Using full dimensionality and guarding will perform the best in place of subsidiary views. |
exception
| 2.01-06a Display on Dashboards for analysis or filtering | Sometimes, to enhance the end user experience, attributes are needed to be shown on pages. Engine Applicability: Classic Hyperblock Only |
| 2.01-06b Ratio formulas | Numeric values for ratios need to be in the same module and are unlikely to need the full dimensionality. Engine Applicability: Classic Hyperblock Only |
| 2.01-06c Synchronization for pages | If you have pages that need to synchronize from a module, sometimes a specific line item is needed. Engine Applicability: Classic Hyperblock Only |
| 2.01-06d Line items needed for sorting | Sometimes to facilitate a sort, the line items don't need the full module dimensionality. Engine Applicability: Classic Hyperblock Only |
| 2.01-06e Reporting or Export modules | To use filtering in reports or to provide attributes for exports (model to model), you may need to have line items for the non-dimensional attributes. Make sure these are set as subsidiary views to minimize the calculations. Engine Applicability: Classic Hyperblock Only |
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.
