Share your ALM best practices — March 2025 Community Challenge

becky.leung

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!

SIVAPRASADPERAM

Hi All, ALM Stands for Application lifecycle management.

Using ALM We can send/move structural changes from one environment to another environment.

Here are some best practices to consider:

1. Model Structure and Data Separation: Keep your development (DEV), test (TEST), and production (PROD) models separate. This helps in maintaining data integrity and security.
2. Revision Tags: Use revision tags to track changes. RT allows to compare and synchronize models effectively.
3. Frequent Small Changes: Implement small, frequent changes rather than large, infrequent ones. This reduces complexity and the time required for synchronization
4. Data Integration: Create separate integrations and schedules for DEV and PROD models to ensure they stay in sync without compromising data integrity.
5. Testing: Always test changes in a TEST environment before deploying them to PROD. This helps in identifying and resolving issues early.
6. Security: Avoid using production data in your DEV model to prevent unauthorized access to sensitive information.
7. Proper Revision Tag Naming
   1. Major.Minor.HistoryID - e.g. 2.1.123456
   2. Or Date.version_HistoryID

Worst Case – ALM is Broken
Create new DEV model from PROD

1. Rename existing DEV model
2. Copy PROD to new DEV (standard mode)
3. In new DEV,
   • Re-create any changes from old DEV – use Compare Revisions to
   see specific changes. Create new Revision Tag
4. Note: this DEV model will not have any prior History or Revision tags. This
   is the case with any copied model.
   • Your old DEV can act has an historical archive (for reference only)

These practices can help to manage Anaplan environment more effectively and ensure smooth transitions between different stages of your application lifecycle.

SunnyNafraz

Few Best Practices:

• "Keep your Dev model clean! Regular metadata cleanup and module optimization will make deployments smoother." (Emphasizes model health)
• "Always validate your deployment packages before pushing to Production. Prevents unexpected changes." (Highlights pre-deployment checks)
• "Use descriptive names for revisions and deployment tags. Makes tracking changes much easier." (Focuses on clear documentation)
• "Document your ALM process! A clear guide ensures everyone follows the same steps." (Stresses process standardization)
• "Leverage line item subsets for ALM. This helps manage changes to specific line items efficiently." (Highlights a specific technical tip)
• "Always use a development workspace, a test workspace, and a production workspace." (reinforces a three workspace strategy)

Deployment Specific Tips:

• "When deploying, carefully review the impact analysis. It shows what's changing and helps identify potential conflicts." (Emphasizes impact analysis)
• "For large deployments, consider breaking them down into smaller, manageable packages. Reduces risk and troubleshooting time." (Suggests a strategy for large changes)
• "After a deployment, always perform thorough testing in the target environment to ensure everything works as expected." (Stresses post-deployment validation)
• "Use selective import during deployment to only update changed items. This speeds up the process and reduces errors." (Highlights a performance optimization)
• "Be mindful of production data during deployments. Avoid overwriting or corrupting it." (Highlights data integrity)

Revision Tag and Branching Tips:

• "Use clear and consistent revision tag naming conventions. Include date, feature, or bug fix details." (Focuses on clear version control)
• "When branching, clearly define the purpose of each branch. Avoid creating unnecessary branches." (Emphasizes efficient branch management)
• "Merge branches regularly to keep them up-to-date with the main development line." (Highlights the importance of regular merges)
• "Use tags to mark significant milestones or releases. This makes it easy to revert to a previous version if needed." (Emphasizes the use of tags for tracking milestones)

Troubleshooting Tips:

• "If a deployment fails, carefully review the error logs. They often provide clues about the cause." (Highlights error log usage)
• "Use the compare feature to identify differences between revisions or deployment packages." (Suggests a tool for comparison)
• "If you're unsure about a change, test it in a non-production environment first." (Reinforces testing in non-production)

Soumyajit

Hi all, ALM is one of the most important part in Anaplan.

In simple words we all know in Application Life Cycle management(ALM) we need 3 models. A Dev model where we do the developments, a Test or UAT model where we first test the development and the Production model where after business approval, we do the deployment.

The Dev model will always be in Standard mode, UAT and Production will be in Deployed mode. UAT model is likely be a copy of the Production model only.

Remember never change the mode of UAT or Production model from Deployed to Standard by mistake. Then this entire ALM chain will break and we wont be able to connect the Dev model with these models for deployment.

We do create a Revision Tag in the Dev model after making the development and then from Manage Models> Compare and Sync we add the changes from Dev model to UAT or Production model.

Make sure if you do this deployment in business hours then always keep the model in Online mode (Uncheck the Offline checkbox in the Revision tag deployment process). If you do this in Offline mode then Business users wont be able to see the Production model until the sync gets completed.

Kanishq17

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

My ALM Best practice for Revision Tag is to use the Last History ID as a Revision tag Title in Dev followed by 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.

KirillKuznetsov

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

Anjaneyulu Putta

Best practices for Application Lifecycle Management (ALM) :

Model Structure and Naming Conventions: Use clear and consistent naming conventions for modules, lists, and actions. This helps in maintaining an organized model and makes it easier for team members to understand and navigate.

Regular Changes: Implement changes in small, manageable increments and synchronize frequently. This reduces the complexity and time required for each synchronization.

Keep Separate Development, Test Environments and Production Environments: Keep your development (DEV), Test (QA) and production (PROD) environments separate. This ensures that changes can be tested thoroughly before being deployed to production.

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

User Access Control: Limit access to the production environment to only those who need it. This minimizes the risk of unauthorized changes and maintains data integrity.

Documentation: Maintain comprehensive documentation of your models and processes.

Use Revision Tags: Utilize revision tags to track changes and manage different versions of your models. This helps in maintaining a clear history of changes and facilitates easier rollbacks if necessary.

Validation: Thoroughly test and validate changes in the development environment before deploying them to production.

mohdtazeem

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

nicolas.brenner

Hello Everyone,

Best Practices for Application Lifecycle Management in Ultra-Distributed Architectures

In our distributed architecture, a single development (DEV) model is deployed across about 70 production (PROD) models, with one PROD model per country. To maintain control and minimize technical support overhead, adhering to best practices in application lifecycle management (ALM) is essential.

Release Process

Step 1: Development Phase

During development, we create one or more revision tags for each new feature, depending on complexity. The revision tag's name is based on the date and time, and its description references the DEV ticket from our project management tool.

Step 2: user acceptance testing (UAT)

During UATs, we create on demand UAT models (fresh copy of a PROD model) and synchronize to the related revision tag. Then we give access to the users and connect the required UX pages. After the validation, the UAT model is archived.

Step 3: Non-Regression Testing

Once development is complete and user acceptance testing (UAT) is finished, we create the release revision tag and initiate non-regression testing:

1. Create Model Copies: Duplicate a PROD model twice: one as the reference model and the other as the regression model.
2. Synchronize Regression Model: Update the regression model to the release revision tag.
3. Execute Key Processes: Run critical workflows on both models (e.g., data hub imports, business processes, and archival tasks).
4. Compare Models: Analyze discrepancies by reviewing exported data, user experience (UX), and master data.

Step 4: Production Model Synchronization

If the non-regression testing is successful, we proceed with PROD model synchronization using an API script. The script follows these steps:

1. Retrieve Revision Tag: Extract the list of revision tags from the DEV model to determine the release revision tag ID.
2. Fetch PROD Model Details: Identify all active PROD models.
3. Record Current Revision: Capture the current revision description for each PROD model.
4. Update to Release Revision: Synchronize each PROD model with the new release revision.
5. Verify Update: Retrieve and compare the new revision description to ensure the update was successful.
6. Log Changes: Document the revision description before and after the update for tracking purposes.

Step 5: UX Synchronization

Following PROD model synchronization, UX updates are applied based on development phase tracking. There are two scenarios:

1. New Page Creation: Connect all PROD models to the newly created page.
2. Existing Page Updates: Apply UX modifications from DEV pages to PROD pages using card templates for efficiency.

General Best Practices

• Maintain Deployed Mode: PROD models should always remain in deployed mode.
• Backup & Archive: Before synchronizing PROD models, create backups and archives.
• Version Control: Store a version number in the DEV model (non-production data) to quickly verify if a PROD model is up to date. This number should be updated just before creating a release revision tag.
• Data Consolidation: Implement a consolidation model to aggregate key data from each PROD model, synchronized via API or model-to-model processes.
• Synchronized Updates: Always synchronize all PROD models simultaneously to maintain consistency across environments.
• On demand test models: During the development phase, create on demand test models (PROD model copy) and synchronized the relevant revision tag for the test.
• Workspace management: UAT and Non-Regression Testing are done in a dedicated workspace. To avoid size issues during the non-regression phase we archive UAT models after each UAT validation.
• Grouping evolutions in releases: To keep control on our backlog, our communication with users and our synchronization window, we group evolutions in releases and define a fixed frequency synchronization plan.

By following these structured ALM practices, we ensure efficient deployment, minimize risks, and maintain the integrity of our distributed architecture.

Pradyumna

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

seymatas1

@SunnyNafraz

To clarify, Anaplan does not currently support true parallel development. Anaplan ALM is linear. All changes in a revision tag must be synchronized at once instead of pushing selected changes.

If real branching & merging were available, we wouldn't need Back to the Future as a workaround.

You can upvote these merging and branching modeling ideas:

ALM - Merge of code branches
Enhance ALM to pick and choose objects to sync with production

Control while syncing changes using ALM

My best practice is to be extra careful when copying and pasting! 🌷🙂

Seyma Tas

Misbah

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!

Navink

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

Poojalakshmi

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.

JohnC

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.

Tiffany.Rice

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:

https://community.anaplan.com/discussion/33595/save-incomplete-changes-when-synchronizing-in-alm

https://community.anaplan.com/discussion/86988/alm-explained-part-3-avoiding-data-loss

https://community.anaplan.com/discussion/159164/how-to-roll-back-a-production-model-to-recover-lost-data

Prajjwal88

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! 🚀

Alessio_Pagliano

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 !

araj

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

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.