Applications Lifecycle Management (ALM) is important for governance, development, and maintenance of your Anaplan use cases.

This article works through how to manage the product lifecycle (governance, development, and maintenance) of your models, as well as apps built in the New User Experience (UX).

With the New UX, you now build pages inside apps. Apps contain all the different pages needed by users when they are analyzing data and planning. Pages connect to a model; they do not live inside a model, as is the case with classic dashboards. This means that they do not sync with ALM when you run a model sync.

It is possible to use the New UX along with ALM. Many customers use the New UX because it delivers a greatly enhanced experience for users. They also use ALM to govern and manage the lifecycle of changes in their models; we will describe how that works and some of the things to think about.

We have a roadmap to enhance the ALM process for apps and pages. Development of Phase 1 is already underway and should roll out in the coming months. With continued investment throughout 2020 and beyond, we’ll deliver better lifecycle management capabilities and make it even easier to build, test, and deploy changes.

UX ALM Process Today and UX Tools to Use Alongside ALM

These tools enable ALM processes today:

  • Duplicate app takes a copy of a complete app with all its pages.

  • Duplicate page takes a copy of a page.

  • Move page moves a page from one app to another. You can use this feature to move a page from a development app to a production app.

  • Change model changes the source model a page is connected to. You can use this feature to remap a page from a development model to a production model.

  • Page access control restricts the access to a page via the roles assigned in the source model the page connects to.

UX ALM Process (Current State)

Initial App Creation or App Replacement:

This example demonstrates how to replace an existing app with an updated app. The same process can be applied when you first create an app, but there'll be no pre-existing app to replace.

  1. Set up one development app (Dev App v2) and one production app (PROD App v1).
    Ensure Dev App v2 connects to a development source model with changes that you want to use to update a production model (DEV model v2).
    Ensure PROD App v1 connects to the production model (PROD model v1).Replace step 1.png

  2. Duplicate Dev App v2.
    Replace step 2.png
  3. Rename the duplicate app to App v2.

  4. Synchronize model changes.

  5. Change the source model of App v2 to PROD model v1.Replace step 3.png

  6. Delete PROD App v1.

Replace step 4.png

Update a Page and Preserve Navigation Links and Personal Pages

This example walks you through the process to update a page alongside model synchronization updates in a way that maintains navigation links and personal pages within the app.

Edits step 1.png

  1. Duplicate a development app (Dev App) and name the duplicate app Dev App Duplicated.Edits step 2.png
  2. Repoint Dev App Duplicated to the production model, PROD model v1.

  3. Delete all pages from the production app (PROD App) that you want to update from Dev App Duplicated or that have navigation links to them.

  4. Create any new categories in PROD App manually.

  5. Synchronize model changes.

  6. Move pages that the synchronization updates from the Dev App Duplicated into PROD App.Edits step 3.png

  7. Delete Dev App Duplicated.

Edits step 4.png


  1. Duplication of pages causes loss of navigation links to other pages. A page that does not have navigation links can be duplicated in the development app and moved to the production app directly (duplicated pages will need to be re-pointed to the correct model and renamed).

  2. When you delete an app, this deletes all personal pages by default. However, in the Delete app dialog, you can select to keep personal pages and remove the link to the app. If you disable My pages for a model, the production app cannot have personal pages. So you can delete and replace the entire production app. If you’ve restricted access to pages in the production app, you need to reapply the restrictions manually.

  3. You should restrict external links to the New UX to the main app landing page for the time being, as these methods change the app IDs in the URLs for individual pages.

  4. After you duplicate an app, you need to reconfigure any forms in the app manually.

UX ALM Future Process


Phase 1: Draft and Publish Pages

Draft pages enable the page builder to edit a page and then save it as a draft. This means they can continue to edit a page in development until the work is complete. They can then publish that page to all users.

Preview page allows page builders to preview a page from designer mode so they can see exactly how it will look and behave in published mode before they publish the complete page.

Page source allows page builders, where model access permits, to change the source model for the page while in draft mode.

This feature enables you to make changes to a page in the draft while the page points at a development model. You can then build out future pages, ready for when you synchronize the development and production models. You can then change the source for the page to the production model and publish the draft page to all users with the changes.

Publish page is the process through which the page builder makes the complete page available to all users.


Phase 2: Multi-page Publish and App Mode

Multi-page publish allows the page builder to publish a selection of draft pages in one go rather than publishing a page by page basis.

App mode enables page builders, where model access restrictions permit, to define which models an app points to for draft pages in development, and published pages in production. This means you can switch mode for the app model source between development, test, and production. This enables you to change the model source to reflect the user's market. For example, the app could point at a UK model or a US model relative to the user.

Page history/versioning/ keeps a log of all changes made to a page. This enables the builder to audit and track any update made to the page and also revert back to previous versions when you require it.

Phase 3: Unified Synchronization and Page Publish Process

The long-term vision is to have a unified ALM process where a page builder can choose to update a model and a set of pages in one unified process. This will include the flexibility to publish just the model, for a structural update, or a single or multi-page update where you need it.

The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.



Thanks for compiling this. I am looking forward to the Implementation of Future Road map for New UX. However I have a few queries


1. Why can't I just Duplicate the app - call it Prod App and change the source Model of this Prod App. Why the need for additional step of duplicating the Dev app and pushing the changes from duplicated Dev app and later deleting it? How is it considered to be best practice?


2. Also when I make any structural change in a model I never used to worry what all dashboard can this have an impact upon. For example changing the logic of my filters. Now with this approach I will have to make sure that I know what all pages are getting impacted and delete those pages and replace it with newer ones. What if I miss any one of the pages?

@Misbah thanks for the feedback.


  1. You can still use this approach and in many cases this makes the most sense. If you are just updating a few pages, want to keep your My Pages within the app or you want to keep the fixed URLs then you can use the second approach.
  2. Not sure I fully understand this point but as stated above you can use the duplicate app method if this works in your use case.