Planual rules regarding Modules.
2.01-01 Follow a consistent naming convention
| Make module names as short as is practical. Use alphanumeric prefixes to help organize and identify modules rather than long names. There is no need to prefix modules in line with DISCO, it is better to align them with functional areas. Engine Applicability: Classic Hyperblock and Polaris |
exception
| 2.01-01a Space saving for user-facing modules | User-facing modules can be renamed to a more descriptive name if required to save on dashboard space, but be mindful of not cramming too much onto a dashboard as per the general design principles. |
relatedToRule
bestPracticesArticles
2.01-02 Use Functional Areas
| Use functional areas to categorize modules. Grouping modules into logical business functions keeps the model organized and makes navigation intuitive for all model builders. Engine Applicability: Classic Hyperblock and Polaris |
2.01-03 Create empty modules to act as separators and facilitate organization
| Use empty modules (modules without any line items) to provide sections and clear ordering to the modules list. Remove the default Time dimension to maintain proper model hygiene, do not use emojis, and apply consistent naming and formatting conventions for all separator modules. Engine Applicability: Classic Hyperblock and Polaris |
relatedToRule
2.01-04 Use the DISCO methodology for module design
Within functional areas, group "like" modules together. Design for the type of module and use the appropriate structures.
bestPracticesArticles
2.01-05 Don't use DISCO as Functional Areas
The DISCO convention is designed to categorize types of modules. Within a functional area you may have multiple types of modules.
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. |
| 2.01-06b Ratio formulas | Numeric values for ratios need to be in the same module and are unlikely to need the full dimensionality. |
| 2.01-06c Synchronization for pages | If you have pages that need to synchronize from a module, sometimes a specific line item is needed. |
| 2.01-06d Line items needed for sorting | Sometimes to facilitate a sort, the line items don't need the full module dimensionality. |
| 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. |
2.01-07 Time Settings module
Create all functions and filters relating only to time in separate modules. They will only re-calculate on model opening and when the time settings change.
It's best practice to use a separate module for each time granularity (week, month, quarter, year, etc.).
2.01-08 Each major hierarchy should have a System module
Create a System module to support all standing data and attributes about the hierarchy (all levels). At a minimum, have the code and parent as line items.
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-10 Avoid summary methods unless strictly required
| Keep the Summary Method set to None for all line items across all module types. Only enable summary methods if all levels of the hierarchy are strictly required for reporting or downstream logic. If all levels are not required, it is more efficient to use the SUM function for downstream aggregation. This practice is critical for very high cell count line items to avoid unnecessary Calculation Effort (both Classic Hyperblock and Polaris) and reduce Populated Cell Count (Polaris Only). Engine Applicability: Classic Hyperblock and Polaris |
exception
| 2.01-10a All aggregation levels are needed | If all aggregation levels are needed, then it's faster to use native aggregation than to use the SUM formula. |
bestPracticesArticles
2.01-11 Keep the Dimension Order consistent
Make sure the dimension order is consistent among modules. Calculations are faster if the common dimensions are in the same order as the Applies To. The size of the list isn't as critical as the order.
bestPracticesArticles
2.01-12 Group formulas with like dimensionality
Create Calculation modules to house sets of line items using the same dimensionality. Avoid using Subsidiary views.
relatedToRule
bestPracticesArticles
2.01-13 Separate Transaction data from Attribute/Property data
Keep the non-time-based data in a separate module from static attributes.
bestPracticesArticles
2.01-14 Avoid using Select Levels and filters together
| Don't use Select Levels combined with filters within UX Pages, Saved Views, or Exports. Select Levels to show acts as a filter before the other filters are applied which can cause additional overhead. Use one or the other to allow for efficient filter evaluation. For hierarchy levels, using Omit summary items in an export layout or setting a Boolean line item in a system module with 'none' as the summary option will often achieve the same result much more efficiently. Engine Applicability: Classic Hyperblock and Polaris |
2.01-15 Filters in separate modules
Try and keep filters in separate System modules. They can then be reused for different modules. In the notes section, describe where and how this filter is used to prevent accidental deletion as the Reference By column won't list filters on views.
relatedToRule
2.01-16 Use Data Tags
If not using for other reasons, use Data Tags to signify the DISCO category.
2.01-17 DCA Access Driver modules
Create separate modules for Access Drivers for relevant combinations to be reused. This helps the overall maintenance and enablement of the model, and it can also help decrease repeated logic. Use different line items for different settings if needed.
2.01-18 Avoid copying large modules
Copying large modules, especially those with filters and many views, can take time and block the model while doing so. For large modules, it's likely to be quicker to re-create the module.
relatedToRule
2.01-19 Put Time and Versions list first in the dimension order
If you're using lists instead of native timescale or native versions, ensure these lists are placed as the first two lists in the dimension order. This mirrors the native time and version settings and will improve performance when mapping between native time/versions and standard lists.
bestPracticesArticles
2.01-20 Use Appropriate Dimensions for modules
When creating a module, consider the scope of the calculation and only include the dimensions that are needed. If the formula doesn't return the value required, or errors, don't keep adding dimensions until it renders the correct data. It's better to review the calculation itself. Check other modules, you may already have a calculation module with the relevant dimensions, so add the calculation in the existing module.
