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:

Save incomplete changes when synchronizing in ALM

DavidSmith

May 31, 2018

Imagine this scenario:

You are in the middle of making changes in your development model and have been doing so for the last few weeks. The changes are not complete and are not ready to synchronize. However, you just received a request for an urgent fix from the user community that is critical for the forthcoming monthly submission. What do you do?

What you don’t want to do is take the model out of deployed mode. You also don’t want to lose all the development work you have been doing. 

Following the procedure below will ensure you can apply the hotfix quickly and keep your development work.

The following diagram illustrates the procedure:

It’s a two-stage process:

Stage 1:

Roll the development model back to a version that doesn’t contain any changes (is the same as production), and apply the hotfix to that version.

1. Add a new revision tag to the development model as a temporary placeholder. (Note the History ID of the last structural change as you'll need it later.)
2. On the development model, use History to restore to a point where development and production were identical (before any changes were made in development).
3. Apply the hotfix.
4. Save a new revision of the development model.
5. Sync the development model with the production model.

Production now has its hotfix.

Stage 2:

Restore the changes to development and apply the hotfix.

1. On the development model, use the History ID from Stage 1 – Step 1 to restore to the version containing all of the development work (minus the hotfix).
2. Reapply the hotfix to this version of development.
3. Create a new revision of the development model.

Development is now back to where it was, with the hotfix now applied.

When your development work is complete, you can promote the new version to production using ALM best practice.

Additional resources:

The procedure is documented in the Fixing Production Issues Anapedia article.

---

View Post

ALM explained—Part 3: avoiding data loss

DavidSmith

Oct 9, 2020

Introduction

In part two of the new ALM Explained series, we discussed the best practices for testing and validating changes prior to deploying them to production models.

However, we also know that testing protocols are not always followed, especially if the change is an emergency patch, and sometimes, the synchronization can cause issues in the production model. There is a defined best practice for “hot fixes”.

If the change needs to be reversed, see part two section on ‘reverting a revision’. However, the worst-case scenario is when a synchronize causes users’ data to be removed, and, in this case, just reverting to the previous revision is not going to restore the data (because data never moves from development to production).

The following are some of the most common examples of how stored data might be overwritten following a synchronization:

• Changing the ‘applies to’ of a module, including subsets of the original list
• Changing the timescale or calendar settings
• Moving the switchover period backward from the current setting
• Adding a formula to a line item that was previously a data entry line item
• Changing the list from production to structural

The first four items are largely self-explanatory, but let's dive deeper into the last one, as this is probably the most common reason for data loss—and the least understood.

Production lists vs. structural lists

Before we look at how data loss occurs, let’s recap the concept of production lists.

Structural information refers to the configuration of the model:

• Lists
• Modules
• Actions
• Model calendar
• etc.

These are elements that cannot be edited in deployed mode; there is no expectation that end users will need to amend these structures.

Production information generally refers to the operational data within the model; for the most part, this will be data entered by users and the users list. When it comes to lists, there are times when we expect that the list's members will need to be amended within a deployed model:

• Importing from a Data Hub
• As part of the operational process, such as promotional planning, or employee assignments to projects

Setting the list as production data prior to setup or a synchronization allows the list members to be added, deleted, or amended within the production model in deployed mode. When the synchronization takes place, only the structural information is transferred; production data never moves from development to production.

For information on Production Lists, see here.

Why do these settings matter?

One of the most common causes of loss of data in a deployed model is changing the list setting from production data back to structural. We need to look in detail at what is actually happening under the covers to explain why.

Each list member has an associated internal id. If the list is set to structural, when the initial synchronization takes place, the lists are different, but the list members are "effectively" the same and have the same ids. For simplicity, I have assumed the id is four alphanumeric characters; in reality, it is 12 digits.

When a new member is added to the list in development, on the next synchronization, this member is added to the list in the production model. Note that no data values are transferred across, as the data remains as production data.

Let’s assume that P1 Products is now set to production data. On the next synchronization, the link between the two lists is broken, but to maintain integrity, the list members and associated data are retained.

When a new item is added into the development model, because the list is production data, this member is not transferred over on the synchronization.

Users are able to add items into the list in production, and these items are not added to the development model.

Now, let’s assume that the list is re-set back to structural. This is where the problem occurs. The production list members are effectively deleted and re-added, they are given new ids, and any data associated with the list members is deleted.

How to recover data

Hopefully, this process will not be needed, but just in case the worst happens, the following steps are a way back. The steps below are able to correct basic issues, such as simple structural changes, or where formulas are added to 'data' line items. Depending on the level of complexity, it may not be possible to restore the data, so it is important to follow the correct testing protocols as outlined in part two of the new ALM Explained series.

As part one explained, models are connected through revision tags, and deployed mode ensures that the compatibility is maintained. This process does mean breaking the golden rule of ALM (‘never take the model out of deployed mode’), but this is an exception. Follow the process below, do not deviate, and you can restore the data lost through an erroneous change while maintaining compatibility.

1. Correct the issue. Identify the cause of the issue and correct it in the development model. This could be a simple change, or quite involved depending on the complexity of the issue.
2. Set a new revision tag for the correction in the development model.
3. Test, test, test. Ensure that this correction fixes the issue and also does not cause any regression issues in other areas.
4. Assuming the test results are as expected and the issue is fixed, synchronize the production model with the latest revision tag set in 2. This will not correct the data loss at this point, but it is a necessary step to correct the structural integrity of the production model.

Now, we have to break the rules

1. In the production model, change the mode to standard, i.e., taking it out of deployed mode.
2. Refer to the history and find the point that the issue occurred. You should be able to see the revision tag and synchronization point in history. Look for a history id immediately below the “Begin sync revision” row.
3. Restore the model to this point; this will remove the structural changes made in the revision that caused the issue. At this point, the data and structures should be restored to a point where the data was correct (so not including the changes are part of the latest revision or the revision that caused the issue).
4. It is tempting now to copy the model to be safe – DO NOT DO THIS – As outlined in part one, copying a model with unsaved structural changes will create a new revision tag to crystallize the changes, and this will break the compatibility.
5. Navigate to the Revision Tag section of Model Settings. You should see the “Revert to Last Revision” button is available.
6. Click this button. This will correct the issue by restoring the structures while leaving the data as it was.
7. As a final step, change the model mode to deployed mode.

Conclusion

Remember, “with great power comes great responsibility.” Follow the rules, test thoroughly, and adhere to best practices to ensure a seamless Application Lifecycle Management process. I hope this three-part series has helped you develop a deeper understanding of the fundamental concepts of ALM so that you can fully utilize the functionality and avoid any pitfalls.

---

View Post

How to roll back a production model to recover lost data

JessieZ

Sep 19, 2024

https://us.v-cdn.net/6037036/uploads/LVVQ8T6UPMIW/data-recovery.jpg

Author: Jessie Zhao is a Solution Architect and Certified Master Anaplanner at Anaplan.

Working with a model in ALM has a lot of benefits. These include building new features in a development model anytime without affecting production users, securely managing production lists by identifying structural data that needs to change in the deployment environment without risking an overwrite, and achieving model synchronization through formal revision control by leveraging the tagging of model changes. But there is one challenge — rolling back the production model to recover lost data is more complex in ALM models because of the potential compatibility issue between the development model and production model.

Recently, it happened that I needed to roll back one production model to restore lost data caused by deletion of ‌list members from a production list. There had been three more revision tags added and a few hundred new inputs added to the production model after the deletion was run. My plan was to roll back to the history ID before the deletion happened to confirm the cause and get a copy of the lost data, and roll forward to the latest user change ID so that the few hundreds user edits between the problematic action and the latest user change wouldn’t be impacted, while I could use the copy to add back the lost data.

Steps I took (hint: don't follow these steps!):

1. Change production model mode from deployed to standard offline.
2. Roll production model back to the history ID before the deletion action with “unlink revision created after this restore point” flagged.
3. Confirm prod model at the ID has lost data and make a copy (I know there'll be a copy revision tag added but will also be removed after Step 4).
4. Roll model forward to the latest user change history ID with ““unlink revision created after this restore point” flagged.
5. Add a new revision tag in Dev model and sync to Prod.
   

Everything looked good as the latest revision tag showed to be compatible to the DEV model initially, but it returned to an error stating that the target model was not compatible to the source model. It was hard to figure out what — except the copy model action — could cause the incompatibility.

For time’s sake, I gave up reconnecting the production model to the original DEV model and started to create a new DEV model from the latest revision tag existing in the production model. But, when I synced the revision tag after DEV model was created, it would return the same incompatibility error. It’s wasn't until I added a new revision tag in the production model first, and created DEV model from this newly created revision tag, did I successfully sync the revision tag between the new DEV and prod model.

To find out what caused the incompatibility, I recreated the issue with a test production model and a test development model and went through the same steps again.

Attempt #2

With more time to compare changes between models, I found that flagging “unlink revision created after this restore point” (revision tag 1) when rolling back and forward the model removed revision tag 2-4 from the production model, but keeping the structural changes made in revision tag 2-4 in production model, which in fact unsaved structural changes in production model. The available “add revision tag” and “revert to last revision” after rolling forward model also confirmed the idea (screenshot 1). At this point, reverting to last revision tag, meaning reverting to revision tag 1 “run delete action for account 7-9", would restore the compatibility (screenshot 2) but changes made in revision tag 2-4 as well as user inputs after the history ID associated with revision tag 1 would be erased. Given that, saving all changes by creating a new revision tag in this production model and creating a new development model would be the solution at this point.

Screenshot 1:

https://us.v-cdn.net/6037036/uploads/5LXQFX9TGY91/picture1.png

Screenshot 2:

https://us.v-cdn.net/6037036/uploads/SEOCIJIBDYP3/picture2.png

Knowing what "unlink" does to the revision tag, I became curious about what would happen if I unflag “unlink revision after this restore point” when rolling back and forward model. I tested the idea and found that revision tag 2-4 will stay, but a new revision tag of copying model as well as history ID associated with it would be added. The copy model revision tag makes the prod model incompatible again and it would need to take the same solution as able to create a new development model, or use the revert feature which potentially could cause user input after revision tag 4 erased.

After the above two tests, I found that unflagging “unlink revisions created after this restore point” when rolling back the prod model to keep structural revisions while flagging the “unlink revision created after this restore point” when rolling forward the production model to eliminate copy model revision tag would be the best way to keep compatibility between the original Dev and Prod models.

The correct steps should be:

1. Change production model mode from deployed to standard offline.
2. Roll production model back to the history ID before the deletion action with “unlink revision created after this restore point” UN-flagged.
3. Confirm prod model at the ID has lost data and make a copy.
4. Roll model forward to the latest user change history ID with “unlink revision created after this restore point” flagged.
5. Add a new revision tag in Dev model and sync to Prod.

Hope my experience of rolling back production model could be helpful for you when you face the same situation!

Questions? Leave a comment!

---

View Post

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.

mohan9550

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.

Stacey_Gibbens

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!

Priya Kumari

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.

michael.moore

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.

Waad

Managing change in Anaplan is all about control, coordination, and confidence. Here’s how I approach ALM to keep things smooth across development, testing, and production:

Environment Strategy

• Dev Model: Daily builds and iteration.
• UAT Model: Mirrors Prod, used for user testing and non-regression testing.
• Prod Model: Locked, stable, and synced via ALM.

Deployment Cadence

• Minor changes: Bi-weekly or on-demand with patches.
• Major releases: Monthly or aligned with planning cycles.
• All changes go through revision tags with clear naming and notes. (e.g., 2025_03_MajorRelease_v1) to make audit and rollback easy.

Testing, Especially Non-Regression

• UAT includes non-regression test suites to validate that existing formulas, dashboards, and integrations still behave as expected.
• Maintain a dedicated “Test Case Tracker” module to record outcomes.
• Use line item subsets and saved views to isolate and verify critical calculations.

Coordinating Model, UX & Integrations

• UX updates are staged in lower environments, tested in UAT, and only then synced to Prod.
• Data integrations are verified in parallel—endpoint consistency and object IDs are critical.

Tips

• Always test the full process flow, not just formulas.
• Don’t skip non-regression testing—it catches unexpected breaks.
• Document changes and test results.
• Automate repeatable tasks wherever possible.

Namdev.Gurme

Mine 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 with name 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.

1. In the development model, set all production lists and production imports (including import data sources), and then add a revision tag.
2. If you want to use a test model:
   1. Create a test model from the latest revision tag in the development model.
   2. Enable deployed mode in the test model.
3. If you don't need a test model, create a production model from the latest revision tag in the development model.
4. Enable deployed mode in the production model.
5. If applicable, use the options in Settings - Source Models to remap model-to-model imports.
6. Make the production model available to end users.