-
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-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
-
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-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…
-
1.07-02 Line Item subsets for Version Formula
Use Line Item subsets to create different numeric formulae for each version to avoid multiple Ifs Best Practice article: Line Item Subsets Demystified Decreasing the Length of Your Formulas Variance Analysis With Native Versions Made Easy
-
1.05-12 Use formulas to derive properties of the list
Based off the code of the list it should be possible to derive the attributes; Calculating the values is more efficient than storing text fields Best Practices article: Data Hubs Purpose and Peak Performance
-
1.05-10 Never delete list and reload the list as a daily occurrence
Clearing and reloading a list increases the structural changes within a model and will increase the likelihood of a of model save, thus increasing the import time. It also removes pre-allocated memory block designed to increase efficiency. Use a unique key to update to values rather than delete and re-load. Also consider…
-
1.05-02 Always use a code
Using codes is more efficient for loading and using lists so strive to always have a code for lists. This is especially important for numbered lists Exception: 1.05-02a Static non hierarchy lists: For simple static lists (such as Yes/No) it is OK not to have a code, but even then, Y and N can be used as codes Related to…
-
1.03-01 Only give write access to lists when needed
Unless the end users need to edit the members of the list (e.g. add, delete), access does not need to be set. Adding roles to lists increases the memory usage, so only use when necessary. A user can edit data in a module without needing to have access to the list Best Practice article: Pre-Allocation in Lists (and Impacts…
-
1.01-01 Never use SELECT with Time
This goes against the Sustainable element of PLANS and the hard coding can cause issues when updating the timescales of the model. Modules with Time formatted items to be used as sums and lookup are the better option Exception: 1.01-01a Generic Time periods: It is OK to use SELECT with Generic Time periods such as Actual…
-
6.05-05 Use a Data hub to populate the Development Model
Use saved views within the Data Hub to populate the Development model. This allows defined data and structures to be imported to assist initial development and component testing
-
6.05-04 Keep the Development model small
Keep the Development model as small as possible. Try and only use a selection of items in the production lists to minimize the model size. Use the “create from revision” functionality as part of the set up Best Practices article: Prepare Applications for ALM
-
6.05-02 Archived Models
Compatible models (DEV, TEST or PROD) can be archived without breaking the link between them Related to Rule: 6.05-03 Model modes Best Practice article: ALM Explained—Part 2: Testing
-
6.05-03 Model modes
When restoring Archived models, restore the model to Deployed mode if this is a Production or Test model Related to Rule: 6.05-02 Archived Models
-
6.05-01 Make DEV the source for everything
DEV> Test, and DEV>Prod is more flexible; it allows multiple Test models, and Test models to be created and deleted without compromising Prod. It also supports segregation of duties Best Practice articles: ALM Explained—Part 1: Compatibility ALM Explained—Part 2: Testing
-
6.04-03 Master Dashboards
Master Dashboards will delete any personal dashboards. Techniques to minimize user disruption include creating a copy and have a migration process to move users to the new dashboards Related to Rule: 4.01-14 Enable Personal Dashboards Best Practices article: Personal Dashboards - Tips and Tricks
-
6.04-02 Switchover
After a revision, create multiple revision tags with different switchover dates prior to starting new development Best Practice article: Managing Frequent Structural Changes During Development
-
6.03-03 Keep Test models in Deployed mode
Test models should be treated as Production Models. This gives a true representation of testing and also prevents inadvertent synchronises from Test to Prod Best Practice article: ALM Explained—Part 2: Testing
-
6.03-02 Use deployed in Dev mode for additional security
Setting deployed mode for Dev models is OK and can prevent inadvertent structural changes being made outside of normal development cycles
-
6.03-01 Don't take the model out of deployed mode
Once ALM has been initiated, and Deployed mode is turned on, the Production model should NEVER be taken out of Deployed mode Exceptions: 6.03-01a Development Model creation - When copying a Production model to create the initial ALM environment, or when re-creating the DEV model as part of a “reset” 6.03-01b There are no…
-
6.02-04 Don't click and hope
Review the referenced by column of potential lists and check for hard coded formula references before checking them as production so you don't generate rollbacks Related to Rule: 6.02-02 Formula protection - Hard coding Best Practice article: ALM Explained—Part 3: Avoiding Data Loss
-
6.02-03 Review the need for Production Lists
Only lists that require amending as part of the business process, or where the lists are populated by imports should be set to production lists Best Practice article: ALM Explained—Part 3: Avoiding Data Loss
-
6.02-02 Formula protection - Hard coding
You cannot hard code a reference to an item in a production list because that member may be deleted by an end user Best Practices article: Formula Protection
-
6.02-01 Define Production lists before the first sync
Don't set all lists to production initially. Setting a list back to Structural (after a synchronize) will remove data from the existing production list even if the members are the exact same Best Practices articles: Prepare Applications for ALM ALM Explained—Part 3: Avoiding Data Loss