Overview 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. Option 1: 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. Option 2: 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 in the Development application. That means that it can be difficult for an end-user or Production Workspace Administrator to know what changes have been made in the current release. To provide release visibility in a Production application, consider creating a Revisions List and Module to store key information about revisions. Revisions List: 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 Remove Time 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: Stage 1: 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. Stage 2: 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: https://community.anaplan.com/t5/Anapedia-Model-Building/Fixing-Production-Issues/ta-p/4839
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. Select Calculation: 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 Proportion: 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 SOLUTION: 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 Lookup Calculation: 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 Calculation: 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 Proportion: 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” Appendix: Blueprints: