Little and Often
Would you leave your Budget submission spreadsheet or your College thesis unsaved for weeks without saving?
The same should apply to making developments and setting Revision Tags. It is recommended that during the development cycle, Revision Tags are set at least once per day. It is also advisable to test the Revision Tags against a dummy model if possible.
The recommended procedure is described below:
After a successful sync to Prod, 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 synchronise 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 Production.
Why is this recommended?
There are a very small number of cases where combinations of structural changes cause a synchronisation error (99% of synchronises are successful). These issues are actively being worked on to provide a resolution within the product, but in most cases, splitting changes between Revision Tags allows the synchronisation to complete. In order to understand the issue when a synchronise fails, our support team need to analyse the structural changes between the revisions.
Setting Revision Tags frequently provides the following benefits:
The amount of changes between Revisions are reduced, meaning issue diagnosis is easier and faster
It provides an early warning of any problems so they can be investigated before they become critical
The last successful Revision Tag allows some, if not most, of the changes to be promoted if appropriate
In some cases, it is possible that a synchronise may fail initially, but when applying the changes in sequence the synchronise completes. Using the example from above:
Synchronises to the Test model for R1, R2 and R3 were all successful, but R3 fails when trying to synchronise to Prod.
Since the Test model successfully synchronised from R2 and then R3, this process can be repeated for the Production model.
The new comparison report provides clear visibility of the changes between Revision Tags.
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.
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.
“Back to the Future”
Imagine the following 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 synchronise. 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?
Well 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 hot fix 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 and has 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:
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). These changes can be made through setting revision tags in the development model. However, you also have a development cycle that spans the structural changes.
What do you do?
Well 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 synchronise 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 synchronise 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 synchronise the model.
Then repeat steps 1) - 3) to set up the next “batch” of revision tags to cover the development window.
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 sub totals
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”
A key step to setting up and using ALM is making sure that Production Data lists are correctly marked within a model. 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 hardcoded 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, he/she 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. This method is only recommended 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. This method is recommended 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. This is useful for 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. This option is recommended 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 used to be 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 the List Selections module has been created with all of the correct line items, you will begin replacing old formulas, which we’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 we need to build a variance report where we have different logic depending on the region, I would start by creating a module by region that has different line items for each different logic that I need similar to the view below:
Once you have the Boolean module set up, you can then change your hardcoded 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.