-
1.01-05 Exclude timescale subtotals by default
Turn the "include" settings off by default and only include these if absolutely necessary. These additional settings (Quarter totals, Year to date, Year to go etc.) will be included in all modules with the model calendar as the time dimension. Thus they will perform calculations on these subtotals. Consider if you really…
-
1.01-03 Use Current Period
Utilising the Current Period within the Time Settings allows the use of CURRENTPERIODSTART(), CURRENTPERIODEND() and can be used to create lookup modules to hold the current period automatically. Exceptions: * 1.01-03a Daily Timescales: The lowest granularity for Time Settings is weekly, so if the Current Period needs to…
-
1.01-02 Use the Model Calendar by default
As the Model Calendar is dynamic, there are a lot of advantages in using it for the majority of modules. Choose suitable time settings (past and future years) that cover most of the requirements and use the model calendar to set these in the most part. For the exceptions outside of the “norm” use time ranges for efficiency…
-
6.04-01 Back to the Future
This is a technique that reverts the model to a previous revision, allows you to make a fix, sync to Production, and then return Development back to where it was Best Practice article: Saving incomplete changes during development
-
1.06-03 Avoid single item subsets
If possible, try and avoid single item subsets, if there is a top level in the list, a single item subset will always have two members. Consider using a Boolean flag in a SYS module or a LOOKUP line item against the desired item (to avoid using SELECT)
-
1.05-11 Do not embed Numeric values or Dates within the Code of a list
Dates and values are "data" and should not be part of a code. Adding these elements to the code will in most cases, vastly increase the size of the list and consequently increase the mode size and reduce performance Best Practices article: Data Hubs Purpose and Peak Performance
-
1.05-07 Avoid Top Level for large flat lists
The calculation for a top level on a large list cannot be split so as the list grows, the calculation becomes increasingly inefficient. Consider if you really need the total. If you need to have the totals, look to add intermediate parent “totals” to make the calculations more efficient, of use SUM to aggregate for…
-
1.05-06 Only use Top Level for ultimate parent
Only use Top level for lists that will need sums so not Currency codes, or True/False (Indicators), or children in composite lists Best Practices article: Top Level Item and Parent Hierarchy
-
1.02-01 Use "Current" in Version settings
Utilising the Current (and Actual) check box within the Version Settings allows the use of CURRENTVERSION() and ACTUALVERSION() in calculations, in SELECT statements and ISCURRENTVERSION and ISACTUALVERSION() for Boolean checks. Current version also acts like a top level for Versions; if you have a source module with…
-
1.02-02 Do not use formulas in the version settings
Whilst this is a simple construct and it might be OK for simple models; it effectively adds size to models every time versions are used in a module even if you don't want the variance. Also, in modules with 3 or more dimensions if you have calculation line items and aggregations the results may not always be give the…
-
1.01-04 Consider All Periods
Consider the use of All Periods. This is effectively the Top Level for time and whilst increasing the model cell count very slightly it does allow for flexibility in modelling. This is especially useful if you need to reference the same calculation many times
-
4.02-09 Publish charts with full filters initially
If the chart has a filtered axis, set the filter such that all items are shown, then publish the chart. Then set the filter criteria back as desired; the chart will then respect the filter
-
4.02-08 Avoid Refresh buttons
Educate the users to use the Refresh option in the toolbar rather than action "refresh" buttons to open dashboards
-
4.02-07 Avoid buttons for Navigation
Use the contents page for navigation rather than clutter the dashboards with buttons Exceptions: 4.02-07a Iterative processes: When the user needs to toggle back and forth between dashboards, it is acceptable to have navigation buttons (old UX)
-
4.02-05 Turn off module page selectors
Show the page selector is appropriate but try and drive the selection from a general page selector Related to Rule: 4.02-04 Add Page Selectors rather than module selectors
-
1.04-02 Utilize Show Content On/Off for Different Functional Areas
To reduce maintenance, create separate Functional Areas for dashboards and modules (e.g. Reports and Report Modules). Consider if you want new content to appear automatically for the end users. For example; In the Contents tab, turn Show New Content "On" for all dashboard Functional Areas and "Off" for all module…
-
1.03-03 Set a landing dashboard by role
Different roles should require a different entry point. Avoid a generic landing page if possible and create a specific dashboard tailored for each role
-
2.04-03 Keep the Default View clean
Keep the default view as is, no hiding line items, filtering, or conditional formatting
-
2.02-19 Don't daisy chain data
Always refer back to the ultimate source if possible, to avoid creating more dependencies than necessary. This allows more parallel calculations to be run increasing efficiency and speeding up calculations Best Practices article: Best Practices for Module Design
-
2.02-17 Put the most common condition first
For formula efficiency, put the conditional with the most common occurrence first in the formula
-
2.02-12 No Hardcoding to List members
Avoid direct references to list item. E.g. IF ITEM(list)=list.xx. Instead, attempt to use a SYS module with a line item having a boolean format as this makes the formula more dynamic (multiple members can use the same logic).
-
2.02-15 FINDITEM on blanks
Doing a FINDITEM() on blank values is inefficient as the function has to traverse the entire list before it returns a blank. If the majority of the values are not blank, then check for BLANK first: * IF ISNOTBLANK(Line Item) THEN FINDITEM(List, line item) ELSE BLANK If the majority are NOT blank: * If ISNOTBLANK(Line Item)…
-
2.02-08 Never use SUM and LOOKUP together
SUM and LOOKUP used in the same expression generally cause large formula calculations and may cause intermediate relationship calculations especially if Time is a dimension or when the source and target structures are very different. Splitting them into different modules and line items considerably reduces the size of the…
-
2.02-05 Create "joins" in smallest hierarchy
If a text string join is needed, create the joins in the smaller lists first to minimize the size of the text strings Related to Rule: 2.02-04 Text Strings Best Practice article: Formula Optimisation in Anaplan
-
2.02-04 Text Strings
Treat text strings with caution. Try and avoid multiple joins and split common joins to separate line items. Make use of IF ISBLANK() when joining text, if the strings are empty set to BLANK. Related to Rule: 2.02-05 Create "joins" in smallest hierarchy 2.03-02 Try not to use TEXT as a format, or limit it as much as…
-
2.02-03 No Repeated expressions
If the expression is repeated in the formula (or other modules), put it on a separate line item. “Calculate once, reference many times”
-
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 will not list filters on views. Related to Rule: 4.02-02 Keep Filters in separate modules
-
2.01-16 Use Data Tags
If not using for other reasons, use Data Tags to signify the DISCO category
-
2.01-14 Avoid using Select Levels and filters together
Don't use Select levels combined with filters on the same hierarchy. It is a double filter and inefficient because both will be kicked off. Use one or the other. Setting a Boolean line item in a System module with 'none' as the summary option will often achieve the same result
-
2.01-13 Separate Transaction data from Attribute/Property data
Keep the non-time-based data in a separate module from static attributes Best Practice article: Data Hubs Purpose and Peak Performance
