Application Lifecycle Management for the User Experience

edited December 2022 in Best Practices

Application Lifecycle Management (ALM) enables your governance, development, and maintenance of Anaplan use cases. You can now work with ALM features in Anaplan’s User Experience (UX) to manage the lifecycle of your pages alongside that of your models.

With the UX, you now build pages inside apps. Apps contain all the different pages users need when analyzing data and planning. Pages connect to models. A page displays data from its source model, but is not a part of the model in the way a dashboard is. Pages do not sync with ALM when you run a model sync.

We’ve developed a roadmap of features to enable you to work with your apps and pages throughout the ALM workflow. Phase one is now complete.

UX ALM paradigm compared to model-sync ALM

ALM for models requires separate models for each lifecycle phase (for example: development, test, and production); changes made in development are promoted through the lifecycle via the model-synchronization functionality.

The vision for UX ALM is to only require a single app to support multiple lifecycle phases. This video visualizes the concept and demonstrates the new functionality:

Note: A single page only displays data from one source model at a time and all the cards on a page display data from the same model. However, the ability to associate multiple models with a page enables you to switch between source models as part of an ALM workflow. When you switch to a new source model, the data that displays on your page and its cards updates.

You can make changes to draft pages based on data from your development model, then publish your changes to end users after you synchronize your development and production models

In the visualization below, the Connected Planning Xperience page on the right in production has an image, text, KPI, and grid cards, which is accessible to users of the two associated production models. On the left, the page’s draft state is connected to the development model and has additional chart and grid cards saved ready for publishing after the ALM model sync process.

UX ALM flow.png

UX features to use support ALM processes

These features enable ALM processes today:

  • Draft pages enable you to create, build, and save new pages to publish later.

  • Preview enables you to view changes to your page as you go, before you publish.

  • Change source model changes the source model from which the page displays data.

  • Multiple source models enable you to associate models from across the application lifecycle (development, test, production) to a single page.

  • Switch between associated models enables users with access to multiple associated models to choose their source model.

  • Duplicate app copies a complete app.

  • Duplicate page copies a page.

  • Move page moves a page from one app to another.

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


UX ALM process today 


Example use cases supported in phase one


Development and production models

Development and many production models Development, test, and production models

Finance Dev

Finance Prod

Finance Dev

Finance Prod EU

Finance Prod NA

Finance Dev

Finance Test

Finance Prod



Changes can be made against Dev and published against Prod when ready


Changes can be made against Dev and published against all Prod models when ready


Changes cannot be published to Test without being published to Prod at the same time. The app or page with all draft changes can be duplicated and repointed at Test until this is natively supported.


Work with draft pages and production models

This example walks you through the process to create and update pages in an app alongside model synchronization updates.

There are three stages to this process:

  1. Create your app and associated models.

  2. Make app changes based on the development model.

  3. Synchronize and publish your changes.


Create your app and associated models

Create your app with pages and associate the models in your ALM flow with those pages.

In this example, we have one app, two pages, and three models (Dev Model, Prod Model A, and Prod Model B) associated with each page.

UX ALM flow diagram 1.png


Make app changes based on the development model

Create new draft pages and save unpublished changes to pages based on structural changes to the development model (shown in green below). These drafts and unpublished changes are not visible to end users until they are published. It's not necessary to create another app to make changes against the development model before you publish them to end users.

UX ALM flow diagram 2.png


Synchronize and publish

Synchronize model changes from the development model to the production models and then publish new draft pages and unpublished changes in published pages. Once you synchronize your development and production model, end users can use these new app components and changes.

UX ALM flow diagram 3.png



After the ALM model synchronization process, all models are up to date in a new version (v2). The app pages are up to date based on the publish process. Note the middle page is still blue in the diagram below because we did not make any changes to this page. 

UX ALM flow diagram 4.png



Work with test models in a development, test, and production workflow

This example describes how the UX ALM functionality can support test models in the lifecycle.

The current UX ALM functionality supports one draft and one published version of a page. It is not yet possible to publish different versions of the page to different associated models (that is Test and Prod).

Example configuration: Consider this configuration where an app with pages is associated with a development and production model.

UX ALM flow diagram 5.png

 Make the necessary changes to your app and pages against the Dev model in draft form.

UX ALM flow diagram 6.png

  1. Duplicate the app (the draft changes are also duplicated).

  2. Once duplicated, update the associated models of the new test app from Dev and Prod to Test.

  3. Synchronize changes from the Dev model to the Test model.

  4. Publish the draft and unpublished changes made to the pages in the duplicated app.

    UX ALM flow diagram 7.png


  5. Invite users to test.
    Once the page changes are published and the pages have been associated with the Test model, users can be directed at the test app to test the latest changes to the app and model before they are published in the original app.

  6. Synchronize model changes to the production model.

  7. Publish the page changes in the original app associated with Dev and Prod.

    UX ALM flow diagram 8.png

  8. Delete the duplicate app.

    UX ALM flow diagram 9.png



Contributing author Chris Marriott.


  • Misbah

    @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.
  • ChrisM

    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

  • Misbah

    @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

  • ChrisM

    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?



  • Is there any way to apply page-level changes in bulk in NUX? I have a small (14-page) app that I would like to update to using two modules per page as described above - currently that's 15 clicks per page to make these changes. I also would like bulk changes for Manage This App > Manage Models, as when copying an app and changing the model, it's painful to have to click through two dropdown boxes per page to make changes. 



  • great point @Hayk .  Currently I'm listing out what page a module is used in the notes section.  Agree their needs to be a easier way to identify where modules are being used in Apps.

  • Tagging onto this thread to keep up to date on how ALM is progressing for apps. I think the current paradigm for having a single app / page linked to multiple models is confusing in its current state.  In my opinion, it would be must easier to follow something similar to the model ALM paradigm, where you sync to push changes from Dev to UAT/Prod, etc.  Ideally syncing page by page or the entire app.

  • CommunityMember127794
    edited March 2023

    @ChrisM what is the status of Phase 2?

    We are now four years into this NUX experiment and, as far as I can tell, still in the Phase 1 implementation that remains painfully flawed.

    The multiple model support feature is neat for tenants who deploy multiple copies on the same model, but in no world is it ALM. It’s like trying to make a silk purse from a sow’s ear.

    As developers, we have to choose between three terrible options.

    1. Use one app, with the very kludgey misapplication of multiple model support, and don't have any end users test our changes prior to publication.
    2. Maintain two entirely separate apps, allowing end users to test prior to deployment in prod, and then manually reproduce the changes in prod.
    3. Do what is described above, save drafts and duplicate pages or entire apps for users to test against before publishing to prod and then delete those test pages. A constant churn of test pages and busy work.

    I will echo the problems highlighted three years ago by @alexpavel and @Hayk above all of which remain unaddressed.

    • change history - who changed which page element when, and what changed
    • revision tags
    • multiple persistent tiers (dev, qa, UAT, stage, prod) with published pages accessible by non-Page Builder testers
    • Controlled and tracked app sync from tier to tier
    • Deployed mode apps that are locked from Page Builder changes
    • Identifying which modules, line items, views, and actions are embedded in which pages (the recently introduced Pages tab is a start, but it still doesn’t address this)

    The current NUX implementation remains an auditability and maintainability nightmare.

  • Charly

    +1 to previous post

    Curious to know the progress of NUX updates to tackle the auditability and maintenance for the developers.

    On a separate note, does anyone have a good workaround for maintaining ability to "Change workspace"? It seems to be either assign one model and be able to quickly change workspace or enable 2+ models and lose ability to change workspace efficiently. Even reverting the multiple source model back to one does not bring back the ability to Change Workspace via drop down.