NEW Community Q&A Challenge — join the discussion and collect a badge!


In the Anaplan Community, we believe that success stems from members connecting, sharing, and helping one another. As we witness members supporting each other daily in forum discussions, sharing ideas and best practices, and showcasing their expertise across various content, we are excited to introduce a new challenge that offers everyone the opportunity to engage and learn from one another.

Introducing our very first Community Q&A Challenge, where we present an Anaplan-related question for all of you to reflect upon and share your perspectives!

Question for the Q&A Challenge: As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

Please comment in this post with your answer!

How to participate in the Q&A Challenge:

  • The challenge starts today, September 5, 2023, and will conclude on September 22, 2023.
  • Provide a response to the Q&A Challenge question by leaving a comment in this post: As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?
  • Community members who participate in the discussion will receive a unique participant badge at the end of the challenge.
  • But that’s not all! In addition to the participant badge, we’re introducing a "Top Answer" badge that will be awarded to the top three responses with the highest number of "likes" from fellow Community members. You can vote for answers by "liking" your preferred responses in the comments. Feel free to "like" more than one answer – in fact, we strongly encourage it!

We will announce the winners of our Q&A Challenge and showcase their answers during the week of September 25!

Are you ready to join the discussion? Participate in the Q&A Challenge by commenting below in this post. Don’t forget to show your support by liking for your favorite answers.

We look forward to seeing your responses!

For a full outline of our challenge rules and restrictions, read our full Terms & Conditions here.



  • Good to see many best practices from different members of Anaplan community.

    Here are few best practices that I have seen or practiced.

    Working mostly in Scaled Agile framework (SAFe), one thing is pretty much clear that development teams need clear guidelines to implement new work or changes so that the process is lean and up to the set standards of delivery.

    Considering a complex scenario where Anaplan is not the only system of planning and relates to upstream and downstream systems, any changes should go through a pre-defined Impact assessment and effort estimates to plan the activities.

    The impact assessment is usually done in tandem with other teams as well which includes IT/Planning and integration team of the source systems (Upstream) and IT/Planning and integration team of the target system (Downstream). It is not a very frequent case as most of the time the changes are limited to Anaplan however in a big transformation project it is good to keep such templates/practice handy so that impact assessment should include communications with other systems as well.

    At the same time, it is also important to review the changes required in Anaplan Sticking to all the standard practices stated by Anaplan including references, imports, exports, filters, DCA , impact in the UX, Workspace size , performance etc. and communicate internally to all the builders and teams who are involved.

    Another important practice should be version management within Anaplan using ALM. A record/Document of which changes are part of which release and using an appropriate naming convention and description for the Revision tags.

    Changes should usually be started once agreed and approved from the concerned stakeholders. As a model builder one may or may not be aware of all the above stated processes but it’s good to have such an understanding at the ground level.

    The last bit is testing the changes. It is good to have a testing environment where teams can test the changes and approve the changes to be released in the production environment.

  • So many great responses here already so I'll provide a less practical perspective.

    In my opinion I think it's important to approach changes with a fearless and pragmatic mindset. Don't be overly cautious and waste time analysing every nuance of a model before feeling ready.

    You'll often simply not have the time to get 100% confident in a change, especially if it's a complicated part of the model. Personally I think trial and error is the most effective and efficient method, especially if you ensure you keep good track of what you are doing.

    Keep in mind what it is your trying to achieve, and remember, you can't really break anything.

  • The comments in this blog have become their own reference tool that a lot of us will refer to in future no doubt! Not sure there is much more I can add but affirming one of the tips that was given here that I also use, and that's not deleting line items immediately. Creating an 'Archived' no data line item, and moving the deprecated line items below it during module change may help as a reference until you know their dependencies have been removed and you no longer need to refer to that original item - even just for context.