PLANS is the new standard for Anaplan modelling; “the way we model”. This will cover more than just the formulas and will include and evolve existing best practices around User Experience and Data Hubs. The initial focus is to develop a set of rules on the structure and detailed design of Anaplan models. This set of rules will provide both a clear route to good model design for the individual Anaplanner, and common guidance on which Anaplanners and reviewers can rely when passing models amongst themselves.
In defining the standard, everything we do will consider or be based around:
Performance – Use the correct structures and formulae to optimise the Hyperblock
Logical – Build the models and formulae more logically – See D.I.S.C.O below
Auditable – Break up formulae for better understanding, performance and maintainability
Necessary – Don’t duplicate expressions, reference data once, no unnecessary calculations
Sustainable – Build with the future in mind, think about process cycles and updates
The standards will be based around three axes:
Performance - How do the structures and formulae impact the performance of the system?
Usability/Auditability - Is the user able to understand how to interact with the functionality?
Sustainability - Can the solution be easily maintained by model builders and support?
We will define the techniques to use that balance the three areas to ensure the optimal design of Anaplan Models and Architecture
As part of Model and Module design we recommend categorising modules as follows:
Data – Data Hubs, Transactional modules, Source data; reference everywhere
Inputs – Design for user entry, minimise the mix of calculations and output
System – Time management, Filters, mappings etc.; reference everywhere
Calculations – Optimise for performance (turn summaries off, combine structures)
Outputs - Reporting modules, minimise data flows out
Making sure that production data lists are correctly marked within a model is a key step to setting up and using ALM . This guide will provide a solution to how someone can make revisions to their model to allow for the tagging of a list as a production data list. Please note: this solution doesn’t work if there are hard-coded references on non-composite summary items. For more information on working with production lists and ragged hierarchies, please visit Production lists and ragged hierarchies logic.
The issue arises as a model administrator needs to tag a production data list, but there are hard-coded references in the model that won’t allow the person to do so. When this occurs and the model administrator tries to tag it as a production list, they will get a warning similar to this:
To fix this issue, all direct formula references to production data lists need to be changed to be indirect references to lists using either LOOKUPs or Boolean formatted conditional logic. Below you will find a step by step guide to replacing these formulas.
Identify formulas with hard-coded references
There are three ways to identify all of the formulas which are hard-coded to production data lists.
Check the list as a production data list and the error that occurs will tell you where the first hard-coded reference is. As you fix one item at a time, the following error will tell you where the next reference is. Anaplan only recommends this method if there are potentially one or two line items that need to be fixed in the model.
Manually scroll through the line items of a model to identify the line items with hard-coded references. We recommend this method if the model administrator has a very good understanding of where all of the hard-coded line items would already reside.
Export the line items with formulas and filter to identify all offenders in the same effort. This option will save significant amounts of time if there are many line items that would need to be changed.
The following instructions will demonstrate how to accomplish option 3 of exporting line items.
Open the model which you are changing production data lists for
Within the settings tab, open Modules and click on the Line Items tab
Export all of the line items
Set a filter on all of the column headers of your Excel ® file
Filter the Formula column and set your filter criteria to the following two criteria (use Contains for both criteria, change the filter from AND to OR)
SELECT: List Name.
ITEM(List Name) =
After following those steps, you should have a list of all of the line items that need to be changed in the model in order for production data list to be open to being checked. Please note: There may still be list properties that have hard-coded references to items. You will need to take note of these as well.
Replacing model formulas:
The next step is to replace these formulas within the model. For this, there are two recommended options.
The first option (Option 1 below) is to replace your SELECT statements with a LOOKUP formula that is referencing a list drop-down. Use this option when there are 1:1 mappings between list items and your formula logic. For example, if you were building out a P&L variance report and needed to select from a specific revenue account, you might use this option.
The second option (Option 2 below) for replacing these formulas is to build a logic module that allows you to use Booleans to select list items and reference these Boolean fields in your formulas. Use this option when there is more complex modeling logic than a 1:1 mapping. For example, you might use this option if you are building a variance report by region and you have different logic for all items under Region 1 (ex: budget – actual) than the items under Region 2 (ex: budget – forecast).
(Option 1) Add List Selections module to be used in LOOKUPs for 1:1 mappings:
From here you should make a module called List Selections, with no lists applied to it and a line item for each list item reference that you previously used in the formulas that will be changed. Each of these line items will be formatted as the list that you are selecting to be production data.
Afterwards, you should have a module that looks similar to this: An easy and effective way to stay organized is to partition and group your line items of similar list formats into the same sections with a section header line item formatted as No Data and a style of "Heading 1."
After the line items have been created, the model administrator should use the list drop-downs to select the appropriate items which are being referenced. As new line items are created in a standard mode model, the model administrator will need to open the deployed model downstream to reselect or copy and paste the list formatted values in this module since this is considered production data.
Remove hard-coding and replace with LOOKUPs:
Once you have created the List Selections module with all of the correct line items, you will begin replacing old formulas, which you’ve identified in Excel, with new references.
For formulas where there is a SELECT statement, you will replace the entire SELECT section of the formula with a LOOKUP to the correct line item in the list selections.
Old Formula = Full PL.Amount[SELECT: Accounts.Product Sales] New Formula = Full PL.Amount[LOOKUP: List Selections.Select Product Sales]
For formulas where there is an IF ITEM(List Name) = List Name.Item, you will replace the second section of the formula after the ‘=’ to directly reference the correct line item in the list selections.
Old Formula = If ITEM(Accounts) = Accounts.Product Sales THEN Full PL.Amount ELSE 0 New Formula = IF ITEM(Accounts) = List Selections.Select Product Sales THEN Full PL.Amount ELSE 0
(Option 2) Modeling for complex logic and many to many relationship:
In the event that you are building more complex modeling logic in your model, you should start by building Boolean references that you can use in your formulas. To accomplish this, you will create a new module with Boolean line items for each logic type that you need. Sticking with the same example as above, if you need to build a variance report where you have different logic depending on the region, start by creating a module by region that has different line items for each different logic that you need similar to the view below:
Once you have the Boolean module set up, you can then change your hard-coded formulas to reference these Boolean formatted line items to write your logic. The formula may look similar to this:
IF Region Logic.Logic 1 THEN logic1 ELSE IF Region Logic.Logic 2 THEN logic2 ELSE IF Region Logic.Logic 3 THEN logic3 ELSE 0
Here is a screenshot of what the end result may look like:
This method can be used across many different use cases and will provide a more efficient way of writing complex formulas while avoiding hard-coding for production data lists.
Selecting production data list:
After all of the hard-coded formulas have been changed in the model, you can navigate back to the Settings tab, and open General Lists. In the Production Data column, check the box for the list that you want to set as a production data list.
Repeat for each list in the model that needs to be a production data list:
For each list in the model that you need to make a production data list, you can repeat the steps throughout this process to successfully remove all hard-coded list references.
Assume the following Non-Composite list, ragged hierarchy that needs to be set to Production Data
We need to refer to the parent to define the logic calculation. In the example, we have assumed that children of Parent 1 and Parent 3 need to return the value 100 and those under Parent 2 and Child 3.1 return 200 and we need to show the proportion of the children.
IF PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Parent 1' OR PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Parent 3' THEN 100 ELSE IF PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Parent 2' OR PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Child 3.1' THEN 200 ELSE 0
Select Calculation / IF PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Parent 1' THEN Select Calculation[SELECT: 'Non-Composite List'.'Parent 1'] ELSE IF PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Parent 2' THEN Select Calculation[SELECT: 'Non-Composite List'.'Parent 2'] ELSE IF PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Parent 3' THEN Select Calculation[SELECT: 'Non-Composite List'.'Parent 3'] ELSE IF PARENT(ITEM('Non-Composite List')) = 'Non-Composite List'.'Child 3.1' THEN Select Calculation[SELECT: 'Non-Composite List'.'Child 3.1'] ELSE 0
These “hard references” will prevent the list being set as a production list
Create a Parents Only list (this could be imported from the Non-Composite list)
Parent Logic? Module
Add Boolean line items for each of the “logic” types
Then you can refer to the logic above
IF Parent Logic?.'Logic 1?'[LOOKUP: Parent Mapping.Parents Only List] THEN 100 ELSE IF Parent Logic?.'Logic 2?'[LOOKUP: Parent Mapping.Parents Only List] THEN 200 ELSE 0
To calculate the proportion calculation without the SELECT, a couple of intermediate modules are needed:
Parent Mapping module
This module maps the Non-Composite parent to the Parents Only list. In this example, the mapping is automatic because the items in the Parents Only list have the same name as those in the Non-Composite list. The mapping could be a manual entry if needed.
The formula and “applies to” are: Non Composite Parent: PARENT(ITEM('Non-Composite List')) Applies to: Non-Composite List
Parents Only List FINDITEM(Parents Only List, NAME(Non Composite Parent)) Applies to: Parents Only List
Parents Only subtotals
An intermediary module is needed hold the subtotals
Parent Logic Calc.Lookup Calculation[SUM: Parent Mapping.Parents Only List]
The final piece is to reference this line item in the original module
Lookup Calculation / Parents Only Subtotals.Calculation[LOOKUP: Parent Mapping.Parents Only List]
The list can now be set as a production list as there are no “hard references”
Imagine the following scenario:
You need to make regular structural changes to a deployed model (for example, weekly changes to the switchover date, or changing the current week). You can make these changes through setting revision tags in the development model. However, you also have a development cycle that spans the structural changes.
What do you do?
What you don’t want to do is take the model out of deployed mode. You also don’t want to lose all the development work you have been doing or synchronize partially developed changes. Don’t worry, following the procedure below will ensure you can manage both.
The following diagram illustrates the procedure (for switchover):
It’s about planning ahead
Before starting development activities:
Change the relevant structural change and set the revision tag.
Create the next revision tag for the next structural change.
Repeat for as many revision tags as necessary.
Give enough breathing space to allow for the normal development activities and probably allow for a couple more just in case.
Now start developing:
When needed, you can synchronize to the relevant revision tag without promoting the partial development changes.
When the development activities are ready, ensure that the correct structural setting is made (e.g. the correct switchover period), create the revision tag and synchronize the model.
Repeat steps 1–3 to set up the next “batch” of revision tags to cover the development window.
“Back to the Future”
Imagine this scenario:
You are in the middle of making changes in your development model and have been doing so for the last few weeks. The changes are not complete and are not ready to synchronize. However, you just received a request for an urgent fix from the user community that is critical for the forthcoming monthly submission. What do you do?
What you don’t want to do is take the model out of deployed mode! You also don’t want to lose all the development work you have been doing.
Don’t worry. Following the procedure below will ensure you can apply the hotfix quickly and keep your development work.
The following diagram illustrates the procedure:
It’s a two-stage process:
Roll the development model back to a version that doesn’t contain any changes (is the same as production) and apply the hotfix to that version.
Add a new revision tag to the development model as a temporary placeholder. (Note the History ID of the last structural change, you'll need it later.)
On the development model, use History to restore to a point where development and production were identical (before any changes were made in development).
Apply the hotfix.
Save a new revision of the development model.
Sync the development model with the production model.
Production now has its hotfix.
Restore the changes to development and apply the hotfix.
On the development model, use the History ID from Stage 1 – Step 1 to restore to the version containing all of the development work (minus the hotfix).
Reapply the hotfix to this version of development.
Create a new revision of the development model.
Development is now back to where it was, now with the hotfix applied.
When your development work is complete, you can promote the new version to production using ALM best practice.
The procedure is documented here:
A revision tag is a snapshot of a model’s structural information at a point in time. Revision tags save all of the structural changes made in an application since the last revision tag was stored. By default, Anaplan allows you to add a title and description when creating a revision tag.
This article covers:
Suggestions for naming revision tags
Creating a revisions tracking list and module
Note: For guidance on when to add revision tags, see When should I add revision tags?
Suggestions for naming revision tags
It’s best to define a standard naming convention for your revision tags early in the model-building process. You may want to discuss with your Anaplan Business Partner or IT group if there is an existing naming convention that would be best to follow. The following suggestions are designed to ensure consistency when there are large number of changes or model builders as well as allow the team to better choose which revision tag to choose when syncing a production application.
1.0 = Major revision/release
1 = Minor changes within a release
In this option, 1.0 indicates the first major release. As subsequent minor changes are tagged, they will be noted as 1.2, 1.3, etc until the next major release: 2.0.
X = Major revision/release
X.1 = Minor changes within a release
In this option, YYYY indicates the year and X indicates the release number. For example, the first major release of 2017, would be: 2017.1. Subsequent minor changes would be tagged: 2017.1.1, 2017.1.2, etc until the next major release of the year: 2017.2.
Creating a revisions tracking list and module
Revision tag descriptions are only visible from within Settings. That means that it can be difficult for an end user to know what changes have been made in the current release. Additionally, there may be times where you want to store additional information about revisions beyond what is in the revision tag description.
To provide release visibility in a production application, consider creating a revisions list and module to store key information about revisions.
In your Development application, create a list called: Revisions
Do not set this list as Production. You want these list members to be visible in your production model
Revisions details module:
In your Development application, create a list called: Revisions Details
Add your Revisions List
Add your Line Items
Since this module will be used to document release updates and changes, consider which of the following may be appropriate:
Details: What changes were made
Date: What date was this revision tag created
Model History ID: What was the Model History ID when this tag was created
Requested By: Who requested these changes?
Tested By: Who tested these changes?
Tested Date: When were these changes tested?
Approved By: Who signed off on these changes?
Note: Standard Selective Access rules apply to your production application. Consider who should be able to see this list and module as part of your application deployment.
There is not a switch to “turn on” ALM.
ALM is based on entitlements described in your subscription agreement
Discuss your subscription with your Anaplan Account Executive and Business Partner
Workspace administrators can check the feature availability:
Log in to Anaplan
Click on your name in the top-right-hand corner
Select Manage Models
Look for the Compare/Sync button
Button is greyed out: Speak to your Anaplan Account Executive regarding your subscription agreement
Button is available: You currently have access to ALM functionality on your workspace.
Additional information is available in the 313 Application Lifecycle Management (ALM) class, located in the education section.
Little and often
Would you spend weeks on your budget submission spreadsheet or your college thesis without once saving it?
The same should apply to making developments and setting revision tags. Anaplan recommends that during the development cycle, you set revision tags at least once per day. We also advise testing the revision tags against a dummy model if possible.
The recommended procedure is as follows:
After a successful sync to your production model, create a dummy model using the ‘Create from Revision’ feature. This will create a small test model with no production list items.
At the end of each day (as a minimum), set a revision tag and attempt to synchronize the test model to this revision tag. The whole process should only take a couple of minutes.
Repeat step 2 until you are ready to promote the changes to your production model.
Why do we recommend this?
There are a very small number of cases where combinations of structural changes cause a synchronization error (99 percent of synchronizations are successful). The Anaplan team is actively working to provide a resolution within the product, but in most cases, splitting changes between revision tags allows the synchronization to complete. In order to understand the issue when a synchronization fails, our support team needs to analyze the structural changes between the revisions.
Setting revision tags frequently provides the following benefits:
The number of changes between revisions is reduced, resulting in easier and faster issue diagnosis
It provides an early warning of any problems so that someone can investigate them before they become critical
The last successful revision tag allows you to promote some, if not most, of the changes if appropriate
In some cases, a synchronization may fail initially, but when applying the changes in sequence the synchronization completes. Using the example from above:
Synchronizations to the test model for R1, R2 and R3 were all successful, but R3 fails when trying to synchronize to production.
Since the test model successfully synchronized from R2 and then R3, you can repeat this process for the production model.
The new comparison report provides clear visibility of the changes between revision tags.
Click here to watch a 7:00 video on this topic