Share your ALM best practices — March 2025 Community Challenge

becky.leung
edited March 4 in Blog

Today, we’re kicking off our first Best Practices Challenge of 2025! This challenge series is an opportunity for Community members to share their expertise on a specific topic, exchange ideas, and learn from one another.

This time, we’re focusing on Application Lifecycle Management (ALM). What is your overall approach to managing changes to your Anaplan environment? How often do you deploy changes to Anaplan? How do you organize your models around your testing strategies? How do you coordinate changes between UX pages and data integrations in conjunction with model changes? Are you leveraging APIs to synchronize deployments across multiple models?

Share your best practices, insights, and lessons learned to help the Community navigate ALM more effectively. We look forward to hearing your perspectives!

How to participate

  • The Best Practices Challenge around model design kicks off today, March 4, and concludes on March 24.
  • Share your best practices related to ALM in Anaplan on this post. Whether it’s a detailed write-up, a short tip, or even a video, we welcome all formats!
  • Explore ALM tips shared by your fellow Community members.

What’s in it for you?

  • Recognition: Showcase your model design expertise and stand out as a Community thought leader! 
  • Learn: Check out contributions from newer and seasoned professionals in the Anaplan ecosystem.
  • Earn a Badge: As a thank you for your participation, everyone who shares their best practices will receive an exclusive Community Challenge badge. It’s a fun way to show off your contribution!
  • Earn a shout-out in our upcoming event: on April 15, we’ll be hosting an event discussing ALM best practices in our upcoming ACE Spotlight: Community Challenge Recap event. Participants' responses will be highlighted at this event.

Participate today

This is a great opportunity to exchange insights, tips, and innovative ideas with fellow Anaplan professionals. Join the ALM Best Practices Challenge to contribute your expertise and learn from others in the Community!

Comments

  • ALM best practice checklist

    1.Ideally Have dev and prod models in separate environments (ALM allows segregation of duties so there is complete possibility of different users in different workspaces as per role and requirement)
    2. In case dev and prod models are in same workspace , ensure no production user is added or provided access to dev model since any structural change can be made ( ensured using security - roles, selective access)
    3.Dev model has to be as lean & small as possible inclined towards Create Model from Revision. Having Production Data in your Dev model is not recommended as you might expose your live data to people.
    4. Use revision tags ( capture the model structure at the time - Note history ID) and name RT properly so that other developers understand and relevant RT can be synced to production
    5. Ensure any data which is to be updated in production model(live to business users ) is marked as production data and before that it is necessary to ensure that list to be marked as prod is not referenced as item format(item reference protection)
    6. while doing compare and sync to sync RT in prod model , do get update as to which RT to push to production ( in case of multiple RT after last sync)
    7. Before syncing any functionality which involves change in production data(update in formula or module data) , it is advisable to keep last production data in hand just before sync since data loss may be caused.
    8. In case of any import needs to be updated in back end in production model, mark import as production import /source as production data
    9.Enable deployed mode in test and production models. Deployed mode locks down your production models so that production users, including Workspace Administrators, can only modify production data, not structural information and deployed mode must not be disabled for production models else compatibility (sync with dev model) can be broken.

  • @Vivekagarwal007 I like your idea of using History ID.

    I myself use just a regular consecutive numbering system in RT Title. And in the description, I would write any notes I feel are related. For example, the name or code of the change request from our tracking system.

  • mohdtazeem
    edited March 10

    Hello All,

    Here is the list of steps I follow for doing any ALM sync, most of them are already covered by our talented community members above:)

    1. Always keep development (DEV), Acceptance (ACC) & production (PRD) workspaces separate to maintain the security & segregation of duties.
      1. DEV model should be in Standard mode. End users should not have access to it.
      2. ACC and PRD models should be in Deployed mode. End users should have proper roles and access to these models.
    2. Set which all model objects are going to be production data (Lists, Actions).
    3. Create relevant user roles a/c to the security matrix. Also, setup correct access to modules, lists, versions, actions/processes & Pages.
    4. Create meaningful RT title and description in DEV model to easier tracking.
    5. It's good to take backup of ACC/PRD model before doing any ALM sync with major changes.
    6. While doing the ALM sync, download/go through the comparison summary to validate the number of changes made in development.
    7. Push the changes to ACC model fist while keeping your target model online. Make sure users have correct roles and selective access to do the UAT.
    8. Let the end users to do the UAT and work on their feedback/suggestions. (Also, setup the end user demos).
    9. Have the proper approvals and sign offs from Stakeholders, COE, End users or any other team involved in the testing/governance before pushing the structural changes to Production environment. (Important specially for new set of changes - Enhancements/go live).
    10. After changes are pushed from development to production, ensure end user role and selective access are properly setup.
    11. Make sure to keep a hypercare period open for the end users do the post-production verification and provide their sign off.

    Thanks

  • Application Lifecycle management(ALM)-Best Practices

    1. Model Structure and Data Separation: Keep development (DEV), test (TEST), and production (PROD) models separate to maintain data integrity and security
    2. Revision Tags: Use revision tags to track changes and synchronize models effectively
    3. Compare and Synchronize: Regularly compare and synchronize changes between models to ensure consistency
    4. Separate Test Workspaces: Use separate test workspaces containing test models with mock data or sanitized production data
    5. Functional Areas: Group dashboards and modules separately using functional areas to streamline testing and user access
    6. Logical Order: Maintain a logical order of lists and actions within modules to facilitate efficient navigation and testing
  • Five questions and each question in itself is an ocean: Let me reply in a succinct way possible

    What is your overall approach to managing changes to your Anaplan environment? ALM is the way to go. I will not add more to it as it has been covered by most of the community members. However, documenting tags is something which becomes extremely important - usually History ID with the sequential order is widely accepted (History ID because you immediately know if you have to restore the model, which History ID should be used to go back). In some cases, creating a separate list of Revision tags and documenting them in the list is also accepted (I personally have never done that)
    How often do you deploy changes to Anaplan? It depends what stage of Implementation are you at. If you are still in Dev stage you can deploy changes almost every day but if the model is live and users are actively using the model, then there has to be a governance around it. Usually once a week is something we consider - ideally frequency of it comes from the Client but recommendations are provided by Anaplan consulting team.
    How do you organize your models around your testing strategies? We create separate testing model for the testers to test with the dummy data. We also create Pre-Prod environment for end users to test with nearly Production data (sanitized prod data) so that they can get confidence in the system by testing with the numbers that they understand.
    How do you coordinate changes between UX pages and data integrations in conjunction with model changes? We document all the changes related to the revision tag prior to pushing the tags to Prod. If there are any UX changes involved they are documented well in advance and as soon as the tags are pushed, UX changes are made immediately. If Data Integrations needs to run after UX changes are published - then we explore the possibility of adhoc runs/manual runs. We don't trouble IT team for such adhoc runs if all the data is within Hub.
    Are you leveraging APIs to synchronize deployments across multiple models? No, never!

  • Hello Community

    Here are some of the practices which I consider following:

    1. Models: Keeping the DEV, TEST, PROD models separate. This helps in maintaining data integrity and security. Ofcourse it depends how we utilize the space to allocate our vision.
    2. Regular Syncs: Regular structural syncs would reduce the development dependencies and also reduces the sync time. And also, it would give a better understanding of the space allocation. Pushing the changes in small packages would reduce the time and complexity.
    3. Integration: Keeping a separate source for DEV and PROD will not compromise data integrity.
    4. UAT: Testing our developments in a TEST Model will save time and sometimes all saves from Data Loss.
    5. Revision Tag Naming: We do use Jira and SNOW for our ticket handling, so I use the ticket ID of Jira or SNOW in the revision Tag. With this we can have a clear idea of what was pushed.

    Question to @becky.leung:
    Can we have Dev, UAT, PROD source data connections in ADO?

    Thanks

  • Hello Everyone,

    Application Lifecycle Management (ALM) is a crucial aspect of working with Anaplan, ensuring smooth development, testing, and deployment of models while maintaining data integrity and security.

    Why is ALM Important?

    Anaplan is often used by businesses for financial, operational, and strategic planning. Changes in these models need to be handled carefully to avoid errors, data loss, or disruptions in ongoing business processes. ALM provides a structured approach to managing these changes, making it easier to:
    →Develop and test new features without impacting live models.
    →Roll back to previous versions if issues arise.
    →Maintain consistency across different environments (Development, Test, and Production).

    Key Components of ALM in Anaplan

    1. Model Lifecycle Management: Anaplan follows a structured approach where changes are made in a Development model, tested in a Test model, and then deployed to a Production model which ensures that updates are validated before impacting end users.
    2. Revision Tags: Every time a structural change is made in a model, a revision tag is created which allows developers to track changes, revert to previous versions, and ensure smooth synchronization between different models.
    3. Development & Deployment Mode: Models in Development Mode allow structural changes like modifying modules, lists, or formulas. In Deployed Mode, the structure is locked to prevent accidental changes, ensuring data security and consistency.
    4. Model Synchronization: ALM enables seamless synchronization between Development and Production models which means you can apply tested changes from one environment to another without manual rework.
    5. Data & Structural Changes Separation: One of the best practices in ALM is keeping structural changes (like formulas, modules, lists) separate from data changes (like transactional data, user inputs) so that business users can continue working without disruptions, even when updates are being deployed.

    Best Practices for Using ALM in Anaplan

    Plan Before Making Changes: Always test modifications in a Development model before pushing them to Production.
    Use Revision Tags Wisely: Document each revision tag clearly to track changes effectively.
    → Keep a Backup Model: Maintaining a copy of your Production model helps in case of unexpected issues.
    → Train Your Team: Ensure that model builders understand ALM principles to avoid accidental changes in live models.

  • ADO does not currently have a mechanism to support Dev / QA and PROD environments. Functionality to support partitioning of objects across environment and / or use cases is on the roadmap and progress towards this capability will be released this year.

    Naming conventions and duplications of objects within ADO can be used to provide separation between Dev / QA and PROD environments in the current release.

  • My best practice is to practice!

    Don't want until there is a production issue to get comfortable with doing a hot fix or unlinking a revision tag via a history roll back. This will feel daunting and scary in a production model but if you can practice in training/sandbox models that can help you get comfortable with the steps. The key is executing in the correct sequence of step and a firm understanding of how to utilize the model history to your benefit.

    A few resources to help you learn the process:

  • Hello Everyone,

    A well-structured ALM approach ensures smooth deployments and minimizes risks. A few best practices I follow:

    • Keep environments separate: Always maintain distinct DEV, TEST, and PROD models to safeguard data integrity and prevent unintended changes.
    • Use meaningful revision tags: A structured naming convention, like @Vivekagarwal007 suggested Last History ID + short description, makes tracking and rollbacks easier
    • Test before deployment: Thoroughly validate changes in TEST before moving to PROD to avoid disruptions.
    • Avoid breaking ALM chains: Never switch UAT or PROD from Deployed to Standard mode, as it disconnects the ALM link.
    • Optimize model performance: Regularly review and refine structures, lists, and integrations to ensure efficiency.

    A well-maintained ALM strategy helps in making deployments predictable and hassle-free! 🚀

  • Hi all !

    Lots of good pots already, meaning it's gonna be difficult to add anything new really. @Tiffany.Rice has just 👆️posted 👆️the key ALM articles.

    The first one in particular is something that many Anaplan veterans would know as the "Back to the future" and something that in many situations you would have come across. And if you didn't, you might 😏And I agree it sounds a bit scary and confusing so I totally recommend to perform a test run of it, in order to feel more comfortable with it.

    A part from that. I think that, whether you are working in a large and well established Anaplan CoE, or at a company that is starting his Anaplan journey, creating and/or refining your Anaplan documentation should be very much linked to how you effectively deploy ALM.

    So if you don't already have it, I think an Anaplan Architecture & Environments document should definitely be the foundation, followed by a Change Management Process.

    Some of the key points/operational considerations worth noting would definitely be :

    • Work with lean DEV models eg use subsets, LISs and production lists as much as possible
    • Perform small and frequent deployments
    • Document Roles&Responsibilities
    • Ensure you have a clear testing strategy
    • Semi-automated checks for validating you aren't braking existing functionality/data. Excel add-in could always be a good option
    • Frequent and regular backups
    • Clear and well auditable naming convention. Consider audit requirements and the fact you might need to review the revision tag history months from now : eg History ID, Jira/US number and clear description works well for me
    • Consider saving comparison reports somewhereand/or having a deployment call to review comparison reports with the technical team. We often do this, particularly at crucial times.

    And one last point/trick. Are you noticing your models are particularly slow when opening the revisions tab ? You might want to re-create the model (therefore purging revision tags). That's because Anaplan is probably checking the revisions tags and the models they have been sync'd to and this is taking up some time.

    Re-creating the model will restore performances from that point of view. But keep the old one as your revision tag history will be gone in the new model.

    I hope it helps !

  • ALM offers great possibilities for stability and testing, to create copies as various important points of the history of the model, segregate duties, etc.

    Below are some points one needs to keep in mind during implementation:

    1. Always create the revision tag by mentioning the history ID for a better track in the future if we need to revert the model.
    2. Its always good to compare the changes between the last RT and the new RT before moving the changes to the production environment.
    3. Ensure the appropriate lists have "production data" checked off.
    4. Always keep a copy of the change log. It's also a good idea to review the change log before you complete the ALM process.
    5. It's good practice to have a QA model for the UAT purpose.
    6. Have a release plan once your model is in production. Plan for maintenance windows
  • Dikshant
    edited March 18

    Separation of Environments: Maintain at least three models—Development, QA (UAT), and Production to ensure changes are properly validated before deployment.

    Release Cycles: Follow a well-defined release cycle (e.g., weekly or biweekly) to bundle and deploy changes rather than frequent ad-hoc updates.

    Testing Strategy: Use a mix of unit testing (module-level validation) and end-to-end testing (cross-functional validation) to ensure changes do not disrupt existing processes.

    Test Data Replication: Maintain test data as close to production in the QA/UAT model as possible to ensure realistic validation.

    Since NUX does not have a compare and sync feature, maintain two apps: one for (DEV) and one for (PROD). Duplicate pages from DEV, move them to PROD, re-link to the PROD model, and remove outdated pages. Use clear naming conventions, track changes, and inform users before updates.

    Use a structured naming convention for revision tags:
    📝 Format:RV.DD.MM.YYYY.LatestHistoryID
    🔹 Example:RV.18.03.2025.20001

    This ensures clarity, easy tracking, and quick rollbacks when managing changes in Anaplan ALM.

    Create daily revision tags to track structural changes effectively. This ensures a well-documented change history for efficient ALM.