-
2.03-03 Headers
Ensure headers are set to No Data to avoid unnecessary calculations
-
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-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,…
-
2.02-21 Try not to use TimeSum
TimeSum should not be used with Time in the Applies To. Instead, attempt to use YEARTODATE or line item[Select: Time. All Periods]
-
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-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…
-
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-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…
-
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-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-09 Aggregation rules (ANY, ALL, FIRSTNONBLANK, LASTNONBLANK)
Utilize these summary methods to minimize the use of additional line items and IF statements
-
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-06 Comparing numbers
It is faster to check A=B rather than A-B=0
-
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-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.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-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-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…
-
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-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: * Best…
-
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-05 Don't Use DISCO 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-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 Best Practices articles: Best Practices for Module Design Reduce Calculations for Better Performance Formula-Structure-for-Performance
-
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-02 Functional Areas
Use functional areas to categorise 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…
-
1.08-01 Don't use Emojis
Don't use Emoji or symbols in any naming of lists, modules, line items, or actions. They can cause issues with integration and different browsers Exception: 1.08-01a Placeholders: It is OK to use Emojis or symbols for placeholders in General Lists, Module Names, Functional Areas etc.
-
1.07-01 Naming Convention
Prefix with LIS: then a description or the module used in the Line Item Subset. For Line item subsets using multiple modules, use a generic name that best describes its purpose Related to Rule: 1.08-01 Don't use Emojis Best Practices article: Good Practice Naming Conventions
-
1.06-01 Naming convention
Prefix the subset with the name of the list (e.g. P3 Products: Active Products) Related to Rule: 1.08-01 Don't use Emojis Best Practices article: Good Practice Naming Conventions
-
1.05-13 Use Flat lists to store Metadata (in a system module)
Avoid having hierarchies in Data Hub; these should only be applicable to the main planning models Related Rule: 5.07-01 No Hierarchies
