Best Practices

Hear from Anaplan experts on the best ways to use the platform.
New Best Practice! This article works through how to manage the product lifecycle (governance, development, and maintenance) of your models, as well as apps built in the UX .
View full article
New Version settings result in more efficient model management and greater flexibility when setting up spoke models using ALM. 
View full article
In part three of the series, learn more about data loss and how to remedy it should it happen.
View full article
An import action section can quickly become disorganized, making ongoing management challenging. Learn why and explore steps to take to prevent this from occurring. 
View full article
In the first of this 3-part series, learn about ALM compatibility and pitfalls. 
View full article
Learn some techniques for testing changes prior to deploying changes to production.
View full article
It is important to understand what Application Lifecycle Management (ALM) enables clients to do within Anaplan. In short, ALM enables clients to effectively manage the development, testing, deployment, and ongoing maintenance of applications in Anaplan. With ALM, it is possible to introduce changes without disrupting business operations by securely and efficiently managing and updating your applications with governance across different environments and quickly and safely deploying changes in your planning cycles as you test and release development changes into production. Common questions to ask before deploying ALM: How are you going to develop your models? Who is going to develop the models? Do you need to segregate responsibilities for development, test, and production models? The overall ALM process can be broadly categorized into five stages:   Design an application that meets your business requirements. You will create user stories, schema diagrams, modules, data flows, wireframes, and prototypes. Build stage, you create the lists and modules that make up the application. At this stage, use sanitized data; don't be concerned about loading production data into your application. Keep the development model small in a separate development workspace. Test the application for performance and user acceptance. To isolate testing from production, utilize a separate test workspace containing test models, and use mock data or a subset of sanitized production data. Deployment introduces the application to end users with full production data. Generally, your production application will be separate from your development and test applications. Importing production data from an external system or data hub might be part of your deployment process. Post-deployment, as you build out an application to address further requirements, the development lifecycle can be repeated as often as necessary. Post-deployment development might include: Fixes to resolve issues, either discovered in production or deferred in the build or test stage. Additional functionality provided by new dashboards, modules, lists, or formulas. New models to support additional business requirements.  We know that change is inevitable. Here are some tips to follow before and during deployment: Create a structure for change. Establish central responsibilities for the process. Establish functional representatives in the business. Designate a central solutions architect. Establish a process for changing / creating a new model. Consider segregation of duties for development and production models/workspaces. Create a change control process. Establish a process for collecting change requests. Clarify requirements with end users. Calculate development estimates (aka level of effort). Define a triage process to prioritize developments. Refer to the Business Owner for approval. Agree on a development or sprint plan. Define a communication plan to the end users. If a data hub (see above) is used, consider the following: Set Imported hierarchies as "Production lists". Set up imports from live data hub into development models. Use saved views and filters to contain the scope of development, test, and production models. Always use development models as the source for both test and production models. Once deployed mode is enabled for production models, do not take the model out of the deployed mode. How do I find out more? Complete the on-demand training on ALM. Review technical documentation in Anapedia. Learn more about the power of ALM: Understanding model synchronization in Anaplan ALM. How does the UX effect ALM?  We currently have features to enable lifecycle management by building pages based on a development model, and then migrating to a production model in the same tenant. The full guide on how to perform lifecycle management with current capabilities in the UX can be found  here . A more unified ALM sync experience for UX is also on the product roadmap, so stay tuned!  Remember to stay up to date on releases and changes to the platform in our platform release blog.
View full article
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.  Don’t worry! 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. 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.) On the development model, use History to restore to a point where development and production were identical (before any changes were made in development). Apply the hotfix. Save a new revision of the development model. Sync the development model with the production model. Production now has its hotfix. Stage 2: Restore the changes to development and apply the hotfix. 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). Reapply the hotfix to this version of development. 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 full article
Model Load: A large and complex model such as 10B cells can take up to 10 minutes to load the first time it's in use after a period of inactivity of 60 minutes. The only way to reduce the load time is by identifying what formula takes most of the time. This requires the Anaplan L3 support (ask for a Model Opening Analysis), but you can reduce the time yourself by applying the formula best practices listed above. One other possible leverage is on list setup: Text properties on a list can increase the load times, and subsets on lists can disproportionately increase load times. It is best practice not to use List Properties but house the attributes in a System model dimensioned by the list.  See Best practice for Module design for more details. Model Save: A model will save when the amount of changes made by end-users exceeds a certain threshold. This action can take several minutes and will be a blocking operation. Administrators have no leverage on model save besides formula optimization and reducing model complexity. Using ALM and Deployed mode increases this threshold, so it is best to use Deployed mode whenever possible. Model Rollback: A model will roll back in some cases of an invalid formula, or when a model builder attempts to adjust a setting that would result in an invalid state. In some large models, the rollback takes approximately the time to open the model, and up to 10 minutes worth of accumulated changes, followed by a model save. The recommendation is to use ALM and have a DEV model which size does not exceed 500M cells, with a production list limited to a few dozen items, and have TEST and PROD models with the full size and large lists. Since no formula editing will happen in TEST or PROD, the model will never rollback after a user action. It can roll back on the DEV model but will take a few seconds only if the model is small.
View full article
Making sure that production data lists are correctly marked within a model is a  key step to setting up and using Application Lifecycle Management (ALM) . This guide will provide a solution to how someone can make revisions to their model to allow for the tagging of a list as a production data list. Please note: this solution doesn’t work if there are hard-coded references on non-composite summary items. For more information on working with production lists and ragged hierarchies, please visit Production lists and ragged hierarchies logic. The issue arises as a model administrator needs to tag a production data list, but there are hard-coded references in the model that won’t allow the person to do so. When this occurs and the model administrator tries to tag it as a production list, they will get a warning similar to this: See  Formula Protection  for more details. To fix this issue, all direct formula references to production data lists need to be changed to be indirect references to lists using either LOOKUPs or Boolean formatted conditional logic.  Below, you will find a step-by-step guide to replacing these formulas. Identify formulas with hard-coded references There is now an easy way to identify all of the formulas which are hard-coded to production data lists. Check the 'Referenced in Formula' column in the General Lists section. This will show the line items where the list is used. Check the respective formula for hard-coded references.  If there are no hard-coded references, then it is OK to check the list as a production data list.  This is the recommended approach, as just setting the lists without prior checking may lead to a rollback error being generated, which could be time-consuming for large models (as well as frustrating). It is possible to just export the General Lists grid to help where there are multiple references for the same list and then use formulas and filters to identify all offenders in the same effort. This option will save significant amounts of time if there are many line items that would need to be changed. You are looking for direct references on the list members: [SELECT: List Name.list member] ITEM(List Name) =List Name.List member The following constructs are valid, but not recommended, as any changes to the names or codes could change the result of calculations: IF CODE(ITEM(List Name))= IF NAME(ITEM(List Name))= After following those steps, you should have a list of all of the line items that need to be changed in the model in order for production data list to be open to being checked. Please note: There may still be list properties that have hard-coded references to items. You will need to take note of these as well, but as per D.I.S.C.O., (Best practice for Module design) we recommend that List Properties are replaced with Line Items in System Modules. Replacing model formulas: The next step is to replace these formulas within the model. For this, there are two recommended options. The first option (Option 1 below) is to replace your SELECT statements with a LOOKUP formula that is referencing a list drop-down. Use this option when there are 1:1 mappings between list items and your formula logic. For example, if you were building out a P&L variance report and needed to select from a specific revenue account, you might use this option.  The second option (Option 2 below) for replacing these formulas is to build a logic module that allows you to use Booleans to select list items and reference these Boolean fields in your formulas. Use this option when there is more complex modeling logic than a 1:1 mapping. For example, you might use this option if you are building a variance report by region and you have different logic for all items under Region 1 (ex: budget – actual) than the items under Region 2 (ex: budget – forecast).  (Option 1) Add List Selections module to be used in LOOKUPs for 1:1 mappings: From here you should make a module called List Selections, with no lists applied to it and a line item for each list item reference that you previously used in the formulas that will be changed. Each of these line items will be formatted as the list that you are selecting to be production data. Afterward, you should have a module that looks similar to this: An easy and effective way to stay organized is to partition and group your line items of similar list formats into the same sections with a section header line item formatted as No Data and a style of "Heading 1." After the line items have been created, the model administrator should use the list drop-downs to select the appropriate items which are being referenced. As new line items are created in a standard mode model, the model administrator will need to open the deployed model downstream to reselect or copy and paste the list formatted values in this module since this is considered production data. Remove hard-coding and replace with LOOKUPs: Once you have created the List Selections module with all of the correct line items, you will begin replacing old formulas, which you’ve identified in Excel, with new references. For formulas where there is a SELECT statement, you will replace the entire SELECT section of the formula with a LOOKUP to the correct line item in the list selections. Example: Old Formula = Full PL.Amount[SELECT: Accounts.Product Sales] New Formula = Full PL.Amount[LOOKUP: List Selections.Select Product Sales] For formulas where there is an IF ITEM (List Name) = List Name Item, you will replace the second section of the formula after the ‘=’ to directly reference the correct line item in the list selections. Example: Old Formula = If ITEM(Accounts) = Accounts.Product Sales THEN Full PL.Amount ELSE 0 New Formula = IF ITEM(Accounts) = List Selections.Select Product Sales THEN Full PL.Amount ELSE 0   (Option 2) Modeling for complex logic and many to many relationship: In the event that you are building more complex modeling logic in your model, you should start by building Boolean references that you can use in your formulas. To accomplish this, you will create a new module with Boolean line items for each logic type that you need. Sticking with the same example as above, if you need to build a variance report where you have different logic depending on the region, start by creating a module by region that has different line items for each different logic that you need similar to the view below: Once you have the Boolean module set up, you can then change your hard-coded formulas to reference these Boolean formatted line items to write your logic. The formula may look similar to this: IF Region Logic.Logic 1 THEN logic1 ELSE IF Region Logic.Logic 2 THEN logic2 ELSE IF Region Logic.Logic 3 THEN logic3 ELSE 0   Here is a screenshot of what the end result may look like:   This method can be used across many different use cases and will provide a more efficient way of writing complex formulas while avoiding hard-coding for production data lists. Selecting production data list: After all of the hard-coded formulas have been changed in the model, you can navigate back to the Settings tab, and open General Lists. In the Production Data column, check the box for the list that you want to set as a production data list. Repeat for each list in the model that needs to be a production data list: For each list in the model that you need to make a production data list, you can repeat the steps throughout this process to successfully remove all hard-coded list references.
View full article
What are the benefits and drawbacks of using Versions instead a General List
View full article
Little and Often Would you spend weeks on your budget submission spreadsheet or your college thesis without once saving it? Probably not. The same should apply to making developments and setting revision tags. Anaplan recommends that during the development cycle, you set revision tags at least once per day. We also advise testing the revision tags against a dummy model if possible. The recommended procedure is as follows: After a successful sync to your production model, create a dummy model using the ‘Create from Revision’ feature. This will create a small test model with no production list items. At the end of each day (as a minimum), set a revision tag and attempt to synchronize the test model to this revision tag. The whole process should only take a couple of minutes. Repeat step 2 until you are ready to promote the changes to your production model. Why Do We Recommend This? There are a very small number of cases where combinations of structural changes cause a synchronization error (99 percent of synchronizations are successful). The Anaplan team is actively working to provide a resolution within the product, but in most cases, splitting changes between revision tags allows the synchronization to complete. In order to understand the issue when a synchronization fails, our support team needs to analyze the structural changes between the revisions. Setting revision tags frequently provides the following benefits: The number of changes between revisions is reduced, resulting in easier and faster issue diagnosis.  It provides an early warning of any problems so that someone can investigate them before they become critical. The last successful revision tag allows you to promote some, if not most, of the changes if appropriate. In some cases, a synchronization may fail initially, but when applying the changes in sequence the synchronization completes. Using the example from above: Synchronizations to the test model for R1, R2, and R3 were all successful, but R3 fails when trying to synchronize to production. Since the test model successfully synchronized from R2 and then R3, you can repeat this process for the production model. The new comparison report provides clear visibility of the changes between revision tags.
View full article
Imagine the Following Scenario: You need to make regular structural changes to a deployed model (for example, weekly changes to the switchover date). You can make these changes by setting revision tags in the development model. However, you also have a development cycle that spans the structural changes. What Do You Do? Let's start with what you don't want to do —take the model out of deployed mode, lose all the development work you have been doing, or synchronize partially developed changes. Don’t worry! Manage these things by following the procedure below. The following diagram illustrates the procedure (for switchover): It’s all about planning ahead.  Before Starting Development Activities: Make the regular structural change (e.g. switchover period) and set a revision tag to preserve this. Create the next revision tag for the next structural change. Repeat for as many revision tags as necessary. Remember to give enough breathing space to allow for the normal development activities and probably allow for a couple more—just in case. Start Developing: When needed, you can synchronize to the relevant revision tag without promoting the partial development changes. When the development activities are ready, ensure that the correct structural setting is made (e.g. the correct switchover period), create the revision tag, and synchronize the model. Repeat steps 1–3 to set up the next “batch” of revision tags to cover the development window.
View full article