Application Lifecycle Management (ALM) enables clients to effectively manage the development, testing, deployment, and ongoing maintenance of applications in Anaplan. With ALM, changes can be introduced without disrupting business operations by securely and efficiently managing and updating your applications with governance across different environments, and quickly deploying changes to run more “what-if” scenarios in your planning cycles as you test and release development changes into production.



This series of videos discuss different aspects of ALM and includes demos performed in a live model.

Part 1 (8:00) click here

  • Benefits of ALM
  • Model modes of ALM (Standard & Deployed)
  • Structural vs Production Data
  • What is a production list?
  • What can and can't be changed in Deployed mode


Part 2 (11:30) click here

  • Revisions and Revision Tags
  • Compatible Models
  • Syncing between Development and Production
  • Model types: Single, Split Model, and Similar Model


Part 3 (11:48) click here

  • Set up - Development only
  • Set up - Production only
  • Set up - Existing Dev/Test/Prod
  • Set up - Simple
  • Set up - With Data Hub


We value your feedback!

If you enjoy the videos please give a Kudo! Leave a comment and let us know if there is other information you would like around ALM. You can also do a search on community for more information around ALM.


Hi Shashishankar, I'm going to send you a PM directly. - Thanks!

Super informative and useful tutorial!

Hi @DavidSmith, this tutorial is great for ALM.  I have one question.  I noticed in the part 3 video that you create the additional environments (DEV, TEST, PROD) by using a model copy (this would enable you to copy data as well as model structure).  In Anaplan Anapedia for ALM, https://help.anaplan.com/anapedia/Content/ALM/Prepare_Existing_Models.html, the instructions have you create new environment using a Revision Tag (only copy model structure).  Is either way acceptable or is one a more current best practice?





When this article was original written, we did not have "create from revision"

Now that we do have, it is recommended to create from revision for a new DEV because we should be looking to keep the DEV as small as possible for efficient modelling.

The copy of Prod to Test is a good strategy when you need to check the latest developments against the up to date set of data.  This is one of the reasons we recommend Dev>Prod and Dev>Test rather than Dev>Test>Prod, you can delete, adjust, create multiple Test environments

I would also recommend setting up different views in the data hub to populate Dev, Test and Prod.

Once the imports to Dev have been set up from saved views in the hub, when Test and Prod models are created, all you need to do is re-point the source models.  This is particularly useful if the scope of the Test model needs to be variable (for testing a specific bug fix, for example)

One final piece of advice and a warning to those who have taken a Prod model out of deployed mode; copying models creates a revision tag automatically, so if you will break compatibility if this copy is done after the initial Dev>Prod sync 

I hope this helps


Thank you! @DavidSmith 

Latest Articles
Hub Model Hierarchy Management
On-Demand Courses
3 weeks ago
On-Demand Courses
3 weeks ago
Effective Dating
On-Demand Courses
3 weeks ago
Automating User Access
On-Demand Courses
3 weeks ago
Selective Access Overview
On-Demand Courses
3 weeks ago
0 Kudos