Lifecycle Management and the New UX

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.

@sprender 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.

@sprender thanks for this article that explains how to manage the apps and pages in Anaplan UX.

I think the purpose of the ALM of the Anaplan NewUX should be to fill in the gap between how currently the classic dashboards are managed and the apps and pages in Anaplan UX. 

Currently, any small modifications made in DEV model in classic dashboards (filters, column widths, formatting, Content flags - security, etc..) I am sure it will be pushed to PROD model at the next push using the classic ALM. Any classic dashboard modification is considered as "structural change". 

Currently, the modifications in DEV apps pages made in Anaplan UX need to be manually traced and the PROD pages need to be first deleted and then moved from the DEV app. 

I think this is what @Misbah intended with point 2. In Anaplan UX, every page-builder needs to manually sign and trace for every modification that has been done to the pages in order to know which pages need to be pushed into PROD. 

Below, some of the gaps between the managing of the "classic dashboards" and Anaplan UX that I hope will be addressed and solved in Anaplan UX:

  1. Make available the historical log of changes in Anaplan UX apps: currently it is not possible to identify who has done and when the modifications to the pages in an Anaplan UX app. It should be possible also to give the opportunity the "Restore to ID" action (similar to the classic historical log).
  2. Create a similar system of "revision tags" for Anaplan UX apps and the tool of the comparisons between different revision tags. this way it will be easy to identify which pages were "touched".
  3. Create the possibility to put a PROD Anaplan UX app in "Deployed mode". this way the page-builders will not be able to make any modifications directly in PROD app and the integrity of the apps will be assured.
  4. Eliminate the need to delete the pages in PROD app in order to be able to copy them from DEV app. This way, when a page will be pushed from DEV to PROD, the PROD page will be "updated" with the modifications made in DEV, and the page internal ID in PROD will be maintained. 



Hi @alexpavel ,

Thanks for your input. I am working on this project with @sprender and hopefully I can give you some reassurance.

1 and 2 - We have plans for a history/version log in Phase 2 - we’ll be sure to incorporate your feedback. We also have plans to highlight to page builders where draft versions exist so changes can more easily be tracked down.

3 and 4 - Phase 2 includes the concept of App Modes which will introduce a more formal process around draft and published versions of pages - this will eliminate the need to delete prod apps to update them with a new version.

I hope this helps

Thanks, Chris

@sprender @ChrisM 


In both these approaches either a page within the PROD APP or the entire PROD APP needs to be deleted but I have a query who is going to do that? I mean I as a consultant wouldn't be having access to Prod Models and hence wouldn't be able to make that change. Are we expecting clients to make that change?


(Edit - @DavidSmith @rob_marshall FYI )


@alexpavel  Thanks for elaborating on that point

Hi @Misbah

I believe the current permissions behaviour is similar to the model synchronisation capability of ALM, ie. the user performing the model synchronisation needs to be a workspace administrator of both the source and target models. Maybe you could send me a message and we could start a conversation about the implications of that current requirement?



Latest Articles
a week ago
User Provisioning
Best Practices
2 weeks ago
by Misbah
Transactional API Tutor
Best Practices
2 weeks ago