Skip to content

    • Share your ALM best practices — March 2025 Community Challenge

    edited March 4 in Blog
    march2025-281-29.png

    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?

    March2025.png
    • 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!

    Tagged:

    Welcome!

    It looks like you're new here. Sign in or register to get started.
    Sign In

    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.

    • 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

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

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

    • Hi Anaplan Community,

      Best Practices for Anaplan Application Lifecycle Management (ALM)

      Application Lifecycle Management (ALM) is used to manage models in Anaplan. It helps us develop, test, and deploy changes smoothly. I wanted to share some easy-to-follow tips and best practices based on what I’ve learned

      1. Model Structure and Data Separation:

      Use Three Models

      • Development (DEV): Where we build and tweak things. Always in Standard mode.
      • QA/UAT: For testing changes. A copy of Production, kept in Deployed mode.
      • Production (PROD): The live model for users. Also in Deployed mode.

      2. Use Revision Tags:

      • Track and synchronize changes effectively using revision tags.

      3. Frequent Small Changes:

      • Implement small, frequent changes to reduce complexity and synchronization time.

      4. Data Integration:

      • Create separate integrations and schedules for DEV and PROD models to ensure synchronization and data integrity.

      5. Thorough Testing

      • Unit Testing:

      Check small pieces (like modules) to make sure they work.

      • End-to-End Testing: Test the whole process to catch more significant issues.

      Keep test data in QA/UAT as close as possible to real Production data for accurate results.

      Always test changes in the TEST environment before deploying to PROD to identify and resolve issues early.

      6. Security Measures:

      • Avoid using production data in the DEV model to prevent unauthorized access to sensitive information.

      7. Proper Revision Tag Naming:

      • Use this format: RV.DD.MM.YYYY.LatestHistoryID
      • Example: RV.18.03.2025.20001
      • Create daily revision tags in DEV to track changes. It makes rollbacks easy if something goes wrong!

      8. Backup and Rollback Plan:

      • Regularly back up models and create a rollback plan in case of issues.

      9. Good Communication:

      • Inform stakeholders about changes, impacts, and expected downtime.
      • Document all changes and steps in a shared space for team alignment.

    • I like to have a frequently refreshed copy of Prod models in Dev Sandbox workspaces that are not used to ALM anywhere. This allows my team to play and test out ideas that might or might not work, without time/schedule pressures. Multiple people can work here at the same time. Unit testing and related workstream regression testing is also performed here.

      Only work that passes the mark in Dev is then manually redeveloped (using detailed documentation) in our Prod Support environment. ONLY specific work items that are approved to move into Prod are redeveloped in Prod Support. This tightly controls what gets into Prod and when it gets there. I like to keep Prod Support “clean” and really only a staging place for imminent ALM or minor break/fix.

      The easiest way to confirm that the redeveloped changes in Prod Support match those in Dev is a cute trick I figured out when working with Anaplan Connect scripts. Common text editors like Notepad++ have text compare plugins available. How the heck will that help, you ask? Copy/paste the blueprint view into Excel and clear out the Cell Count and Calculation Effort columns (they could be different in each version of a model). Save as .csv or tab delimited .txt files and use the text compare function to identify any variances!!! Easy Peasy Lemon Squeezy!

      Correct any discrepancies, create your revision tag, and you’re good to go!

    • edited March 24

      Hello Community Members,

      As requested, here are the best practices for ALM to be followed for Anaplan environment:

      Application Lifecycle Management (ALM):

      ALM is a process that move the structural changes from one environment to different environments and enables the effective management of the development, testing, deployment, and ongoing maintenance of applications.

      1.Model Structure and Data Separation:

      Maintain separate models for Development, User Acceptance Testing (UAT), and Production.

      >Development Model: This model is kept in standard mode to facilitate ongoing development and testing of new changes.

      >UAT Model: A copy of the Production model, the UAT model is kept in deployed mode to mirror the production environment for thorough testing.

      Note: All changes are first tested in the UAT model to validate their functionality and impact.

      >Production Model: The live environment, also kept in deployed mode, ensuring stability and reliability.

      Note: Once data is validated in UAT, changes are moved to the Production model to ensure seamless integration and minimal disruption.

      Roles and Access: Roles and access permissions are carefully assigned in both the UAT and Production models to ensure security and appropriate access levels.

      Mode Integrity: The modes of the UAT and Production models are never changed to standard mode, maintaining their deployed status for consistency and reliability.

      2. Revision Tags:

      Use clear and descriptive names for revision tags to indicate the purpose or nature of the changes. This makes it easier to understand the context of each tag.

      >ALM Best practice for Revision Tag: Use Last History ID as a Revision tag Title.

      Example:

      • Use this format:DD.MM.YYYY.LatestHistoryID
      • Example: 23.03.2025.1234
      • Create daily revision tags in DEV to track changes. It makes rollbacks easy if something goes wrong.

      Descriptions: Give a short description of the contents by comparing the previous and Current tag. This helps reach the point in time where we completed the development and helps track changes better.

      3. Frequent Deployment in Anaplan: Implement small, frequent changes rather than large ones. This reduces complexity and the time required for synchronization.

      Note:

      >After a deployment, always perform thorough testing in the target environment to ensure everything works as expected.

      >After changes are pushed from development to production, ensure end user role and selective access are properly setup.

      4. Regular Backups:

      Regularly back up your models to prevent data loss and ensure you can revert to a previous state if needed.

      Step 5: UX Synchronization

      After synchronizing the PROD model, UX updates are implemented according to the development phase tracking. This involves two scenarios:

      1. New Page Creation: Link all PROD models to the newly created page.
      2. Existing Page Updates: Transfer UX changes from DEV pages to PROD pages using card templates for streamlined efficiency.

      Note: By following these steps, we ensure that UX updates are applied consistently and efficiently across all models.

    • Great ALM best practices shared already! Rather than repeat previous recommendations, I only have a few additions:

      Revision Tag naming: Include User Story ID or Bug ID in revision tag description. These link to more detailed descriptions of the requirements driving changes.

      Sync multiple models using API: Use the Application Lifecycle Management API to sync multiple models at the same time. For organizations with multiple production models (by geography or other dimension), building a custom tool to sync multiple models with one user action can save time and standardize the process.

      Segregation of duties: Limit workspace admin roles to enforce segregation of duties. Only the implementation team has workspace admin access to the source model in standard mode. Only the operations team has workspace admin access to production models in deployed mode. Both teams have workspace admin access to the testing workspace. Moving anything to production requires at least two different people which provides two opportunities to catch a mistake.

      "Practice" models for large teams: Where large teams contribute to a single source model, encourage them to first build and test their model changes on a standard-mode copy of the "official" ALM source model. When their changes are ready, the model builders manually copy changes to the source model to be sync'd to test and production. Each model builder can have their own "practice" model, or small sub-teams can share one. Formula and format errors in practice models impact fewer other model builders.

    Welcome!

    It looks like you're new here. Sign in or register to get started.
    Sign In

    Welcome!

    It looks like you're new here. Sign in or register to get started.
    Sign In

    Quick Links

    Categories