Model structure changes without ALM


Hi All,

I am looking for some guidance around model structure changes. We currently don’t use Application Lifecycle Management. Can anyone share some thoughts on best practices please? What's the best way to implement model changes? Can we do it during business hours? How do we ensure no one is working in production at the same time we implement the changes? 


Many thanks,



  • @Karolina_SKY ,


    So obviously, managing model changes is much easier with ALM as ALM takes a "snapshot" of the model and promotes the changes to Production.  If you don't have ALM, you will have to recreate all new objects (lists, modules, subsets, line items, views, actions, dashboards, etc) manually in the production model and make sure you capture all of the development.  So, without ALM, it can be very tedious, especially if you miss something.  Essentially, this is what we had to do prior to ALM.


    As for Best Practices without ALM, the administrator or model builder, will have know and understand everything that has been built and what needs to be recreated, as well as the order it needs to be created in (can't create an action from a view without the view or module being created first).  As far as when to do the changes, I would recommend in off hours in case you have a rollback (bad formula) so you don't impact the users too much or you can take the system Offline which locks everyone out except for model builders (workspace admins).


    Hope this helps,



  • dkolka


    In addition to what Rob highlighted, Revision Tags can be utilized to manage change within a Customers Model Landscape even if ALM is not being used. Along with that and if your IT department doesn't have utilize a code management a separate logging Dashboard can be devised to track detailed change.

    Here are some additional details on Revision Tag functionality.


    A few Key Points to Consider

    • Track all significant changes manually or in change management system
    • Use Revision Tags to compartmentalize key solution changes details of which are in the change log
    • Utilize Anaplan Functional Area, shell Modules and List to categorize new development work in Anaplan
    • Maintain 4 Environments (sounds like a lot and this very dependent on your Environment)
    1. Sandbox - Perform ‘Green field’ development here.  This could be your personal space. New functionality is moved to Dev.
    2. Dev - Finalized solutions are built here and synced with existing functionality.
    3. Test - Dev solutions are promoted (ALM or manually) to Test for extensive testing by admins and even for UAT
    4. Prod - Once testing is approved again promote Dev solutions to Prod as was done for Test
    • When starting a new solution Create a new Dev from the Prod Model
    • Publish to the user base none maintenance windows.
    • Communicate day before and day of the outage is coming
    • Typically maintenance windows occur  on Thu/Fri/Sat - this provides time to remedy issues before Monday


    These are just a few common best practices for software solutions.  Hopefully some of these help for your particular situation.





  • dkolka
    Hi, as a follow on to the documentation component this is a very good article.