-
5.07-04 Get the correct format
Get the data from IT in the correct format as well as the correct granularity Related to Rule: 5.04-06 Import the correct granularity
-
5.07-03 Flat lists for data export
Use the flat list structures to create modules and views for downstream exports
-
5.07-02 No Analytical modules
Try and keep Analytical modules out of the Hub
-
5.07-01 No Hierarchies
There should be no need for composite list hierarchies in the Hub. They can be built to "test" the actions, but after testing they should be deleted Exceptions: 5.07-01a Validation purposes: If data is needed to be consolidated to check against source systems, although the flat modules with attributes can be used to sum…
-
5.05-04 Ensure view filters are optimized
Only use one filter criteria...If more are needed, combine them into one line item Related to Rule: 4.02-01 Use efficient filters Best Practices article: Filter Best Practice
-
5.05-03 Split views for List and Module imports
Create two views from a source module. One for the import to the list (using name, code and parent), and a view for the attributes to the associated System module Related to Rule: 5.05-02 Only include what is needed
-
5.05-02 Only include what is needed
Only include the line items that are required for the import. Create multiple views if the module is used for different imports. The number of columns in the view does affect the speed of the import. The fewer the columns, the faster the import will be
-
5.04-09 Always use saved views as import sources
Modules and saved views should be used as the source for other imports Best Practice article: Filter Best Practice
-
5.04-08 Never use a list as an import source
Import sources should always be done from a module view. This allows for filtering and only including the elements required for each import
-
5.04-07 Import using the correct formats
Line items holding the Imported line items should reflect the data. List formatted, numbers, and dates. Don’t use text (unless it is a true text field)
-
5.04-06 Import the correct granularity
Only imported data at the granularity needed. There is no need to bring in transactional data at a weekly level when Planning happens at the month level
-
5.04-05 Pre aggregate in the source
Wherever possible, aggregations should be done in the source system. This is likely to reduce the size of the import file meaning faster imports
-
5.04-04 Only include the fields that are needed
Use the Ignore field if there are any unwanted fields in the source data
-
5.04-02 Create separate files for attributes and data
The data file should have the key and values based on the dimensions. Non dimensional data should be in a different file Related to Rule: 5.04-01 From source system, create a code defining all attributes Best Practice article: Data Hubs: Purpose and Peak Performance
-
5.04-01 From source system, create a code defining all attributes
Ideally, this would be a separate file that is unique vs. using the same file for the transactional load Exception: 5.04-01a Code is >60 characters: If the code is >60 characters, you will have to use combination of properties Related to Rule: 5.04-02 Create separate files for attributes and data Best Practice article:…
-
5.02-02 Keep actions in a process to a minimum
Each action in a process triggers a recalculation so try and minimize the number of actions
-
5.01-03 Keep User actions (in general) to a minimum
Critically review the need for user driven actions, consider the effect on user concurrency. Attempt to use formulas instead. This may need additional modules, but the user experience could be improved as a result
-
4.03-02 Keep Filters in separate modules
Try and keep filters in separate System modules. They can then be reused for different modules Relate to Rule: 2.01-15 Filters in separate modules
-
3.06-02 Instructions
Use text and instructions where possible, although keep it simple and don't overwhelm the user with verbose language
-
3.03-04 Split it up
Consider using multiple pages instead of putting all elements on one
-
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.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-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-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