Register

Chapter 2

Modules

2.01-01 Naming Convention

As short as is practical.  Use Alpha numeric to help identify modules from long names.  There is no need to prefix modules in line with DISCO. It is better to align them with functional areas

 

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

 

Related to Rule:
4.02-10 Turn off the Module Name

 

Best Practice article:
Naming Conventions

2.01-02 Functional Areas

Use functional areas to categorise modules

2.01-03 Add "Dummy" Modules as Separators

Use these to provide sections and ordering to the Modules list, but don't use Emojis

 

Related to Rule:
1.08-01 Don't use Emojis

2.01-04 Use the D.I.S.C.O. Methodology for Module Design

Within functional areas, group "like" modules together.  Design for the type of module and use the appropriate structures

 

Best Practices articles:
Best Practices for Module Design
Reduce Calculations for Better Performance
Formula-Structure-for-Performance

2.01-05 Don't Use D.I.S.C.O. as Functional Areas

The DISCO convention is designed to categorise types of modules. Within a functional area you may have multiple types of modules

 

Exception:
2.01-05a Simple models: If the model is simple, DISCO can be used as the naming for functional areas

 

Related to Rule:
2.01-04 Use the DISCO methodology for Module design

2.01-06 Avoid Using Subsidiary Views

Subsidiary views are difficult to work with and audit.  Try and minimise their use especially for calculation modules; create groups of calculation modules instead with like dimensionality

 

Exceptions:

2.01-06a Display on Dashboards for analysis or filtering: Sometimes, to enhance the end user experience, attributes are needed to be shown on dashboards
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 some dashboards: If you have dashboards that need to synchronize from a module, sometimes a specific line item is needed (Old UX)
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 utilize filtering in reports or to provide attributes for exports (model to model), you may need to have line items for the non-dimensional attributes. Ensure 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 is best practice to use a separate module for each time granularity (e.g. by 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: If the hierarchy is not referenced in a formula, as a filter or a selector module on a dashboard then it is not needed

Best Practice article:

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 are also useful within an Application Lifecycle Management (ALM) set up

 

Related to Rule:
2.02-14 Avoid using SELECT

2.01-10 Calculation Modules

Turn off summary options by default.  It is better to use SUM for any downstream aggregation if not all levels are needed

 

Exception:

2.01-10a All aggregation levels are needed: If all aggregation levels are needed, then it is faster to use the native aggregation than use SUM formula

Related to Rule:
2.03-01 Turn Summary options off by default

 

Best Practices articles:

Reduce Calculations for Better Performance
Formula Structure for Performance

2.01-11 Keep the Dimension Order consistent

Ensure 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 is not as critical as the order

 

Best Practices article:
Dimension Order

2.01-12 Group formulas with like dimensionality

Create Calculation modules to house sets of line items that use the same dimensionality. Avoid using Subsidiary views

 

Related to Rule:
2.01-06 Avoid using Subsidiary Views

 

Best Practices article:
Line Item Subsets Demystified
Decreasing the Length of Your Formulas

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

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-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-17 DCA Access Driver modules

Create separate modules for Access Drivers for relevant combinations to be reused.  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 some time and block the model whilst doing so.  For large modules, it is likely to be quicker to re-create the module

 

Related to rule:

2.04-03: Keep the default view clean 

2.01-19 Put Time and Versions list first in the dimension order

If you are 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 which will improve performance when mapping between native time/versions and standard lists

 

Best Practice Article:

Dimension Order 

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 does; it is 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

Related to Rule:

2-01-04 Use the D-I-S-C-O Methodology for Module Design 

Best Practice Article:

Reduce Calculations for Better Performance 

Formulas

2.02-01 Nested IFs

Avoid using multiple IFs.  It is better to split the formula into more line items, use LOOKUPs or alternative constructs

 

Best Practices article:
Line Item Subsets Demystified
Decreasing the Length of Your Formulas

2.02-02 < 12 expressions in a formula

If it takes you longer than one simple sentence to describe what the formula is doing, it is probably too long.  Try not to mix expressions

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.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 possible

 

Best Practices articles:
Formula Optimisation in Anaplan

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-06 Comparing numbers

It is faster to check A=B rather than A-B=0

2.02-07 Use Booleans instead of 1s & 0s

Booleans take up 1/8th of the space as a number, so unless a numeric value is needed use TRUE or FALSE

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 intermediate calculations

 

Exception:

2.02-08a The LOOKUP is a constant: Where the LOOKUP line item is a constant, the formula will operate as a SELECT, so the performance implications are negated

 

Best Practice article:
Formulas and their effect on model performance

2.02-09 Aggregation rules (ANY, ALL, FIRSTNONBLANK, LASTNONBLANK)

Utilize these summary methods to minimize the use of additional line items and IF statements

2.02-10 Using PREVIOUS() vs CUMULATE()

For long timescales, using PREVIOUS is faster than CUMULATE due to the number of "reads" required for the calculation.  So, the expression should be: 'Calc line item' = 'data line item' + PREVIOUS('Calc line item') rather than CUMULATE('data line item')

 

Exception:
2.02-10a Short Timescales: Where the number of periods is small, Cumulate is faster

 

Best Practice article:
Performance Issues with Cumulate Over Lists

2.02-11 Avoid using TEXTLIST()

TEXTLIST() requires a lot of memory for calculations and should be avoided if possible, using two dimensional modules and Boolean flags with ANY is a good alternative.  Other alternatives are using FIRSTNONBLANK as well as LASTNONBLANK.

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-13 Only use POST for its specific purpose

Don't use POST for simple data offsets.  OFFSET, LAG or MOVINGSUM are more efficient

2.02-14 Avoid using SELECT

Avoid hard coding using SELECT if possible.  Use a constants module and use LOOKUP instead

 

Exceptions:
2.02-14a Versions: It is OK to use SELECT for versions
2.02-14b For top level items on non-composite lists: In Non-Composite lists, it is not possible to use LOOKUP to return the value, so it is OK to reference the Top Level item with SELECT.  For other items, it is better to use dummy parent lists and additional modules

Related to Rule:
1.01-01 Never use SELECT with Time

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 blank:

  • If ISBLANK(Line Item) THEN FINDITEM(List, line item) ELSE BLANK

If there will never be blanks in the values, there is no need to check for blanks:

  • FINDITEM(List, line item)

Related to Rule: 
2.02-17 Put the most common condition first 

 

2.02-16 Use conditionals to stop unnecessary calculations

In multiple conditional statements, try and include a conditional to prevent further referencing in the formula if the condition is satisfied

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-18 Break up formulas

The engine works more efficiently when calculations are broken up into separate line items. So, break up formula expressions where possible. This is especially true for calculations that are referenced many times and/or calculations that don't change that often

 

Best Practice articles:
Formula Structure for Performance
Formula Optimization in Anaplan

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-20 Don't use RANK formulas with large lists

RANK is a calculation intensive formula that cannot multi thread.  Used in conjunction with large lists it can lead to poorly performing calculations.  The same applies to RANKCUMULATE
Exceptions to this are when the formula also applies to Time.

2.02-21 Don't use TIMESUM with Time

TIMESUM formulas should not be used in a line item that applies to Time, the formula will be duplicated for each time period.
If the TIMESUM does use time periods then consider using MOVINGSUM instead.



Line Items

2.03-01 Turn Summary options off by default

Most line items in the model will not need summary calculations, so it is good practice to turn summaries off initially and add then back when necessary. This is especially true for Calculation modules and conditional formatting line items

 

Exception:
2.03-01a User facing modules on dashboards: For Input or Output modules, specifically those line items displayed on Dashboards, summary options are likely to be needed

 

Related to Rule:
2.01-10 Calculation Modules

2.03-02 Try not to use TEXT as a format, or limit it as much as possible

Anaplan (as with computers in general) is optimized for numbers and Booleans. Text formats use more memory than any other format due to the way computers need to store the data.  Minimize the use of text if possible.

Set to BLANK rather than leave empty or invalid text.

 

Related to Rule:
2.02-04 Text Strings

2.03-03 Headers

Ensure headers are set to No Data to avoid unnecessary calculations

Saved Views

2.04-01 Naming convention

Give the view a meaningful name (e.g. Dashboard Grid, Filtered View, Export etc.) There is no need to add the module name within the name of the view

 

Best Practice article:
Naming Convention

2.04-02 Filtering on views

Filter on a Boolean and only have one filter per dimensional tab

 

Related to Rule: 
4.03-01 Use efficient filters

 

Best Practice article:
Filter Best Practice

2.04-03 Keep the Default View clean

Keep the default view as is, no hiding line items, filtering, or conditional formatting

2.04-04 Nested Views

If possible, nest the dimensions in order of size (largest to smallest)

Knowledge Base Dashboard