Ability to select versions as a list formatted line item for use in lookup statements


Versions are useful as they allow switchover functionality enabling a user to both enter a forecast on a line and see actuals in the same line item. However, comparing versions to eachother (any version to any other version dynamically) requires a "Versions List" and logic to engage that list with the Version you want to pull with [SELECT:VERSIONS.(verions name here]. If Version could be a format of a line item, then Anaplan reporting out of version would be greatly enhanced as these version formatted line items could be used in Lookup statements.

172 votes

In Review · Last Updated


  • following. 

  • Status changed to: In Review
  • Status changed to: In Review

    This was also suggested in previous posts (example 7 FEB 2018, https://community.anaplan.com/t5/Locked-Product-Requests-for/Version-as-option-for-Format-of-a-line-...) , would really be great to have this implemented! And in this post: https://community.anaplan.com/t5/Idea-Exchange/Version-subsets-and-selection-as-a-formats/idc-p/39544#M1559

    Please add this?

  • Hi All, some good news...

    This has been put on the long-term roadmap, see link below.
    But the short term list wouold be nicer. Maybe by consolidating kudos, because saw several similar request..


    Thanks a lot!


  • dkangrga


  • This would be a large piece of work. We will consider it for our longer-term roadmap. 

  • mpeck

    +1 please add

  • @Rebecca is there an update? It's been exactly 1 year since your post. 🙂

  • Yes, an update would be nice. This request has 126 votes and was submitted almost 2 years ago

  • Another vote for this functionality

  • need this one. +1 vote

  • Status check: 156 votes and was submitted 3 years ago. This functionality is still needed.

  • It is quite unsatisfying that this feature is still pending. The most likely proposed solution for that problem is to build a own version dimension and use this instead. But the consquence of that would be the disability to use build in functions, like switch over date and formula scopes. Additionally this would practically eliminate any future use of an official feature based on the official  versions, since that would need a complete rework of the custom solution.


    In conclusion we decided to go with the official version list, to hardcode those usecases and pray that anaplan will receive an official update.

  • Indeed, it means that in most cases you have to use a custom version dimension, while the switch-over functionality is promoted. We always have to explain why we are not using it.

  • I second the recent comments and would like to add...  come on man. 


    This limitation ultimately leads to more implementation time on EVERY SINGLE PROJECT.  This means all implementations estimates are up to cover this which makes us less competitive. Beyond that basic point there is the issue of ongoing usability and maintenance for a system riddled with snapshot modules.


    Which drives me to the last point. As long as we are addressing this, could we also address the inability to pass formatting or summary configuration through a LISS refenced module.  This also creates complexity in all snapshot variance modules. 


    "Come on baby light that fire"

           ~The Doors



  • For those with the opportunity to do so,  choosing a version list approach should be considered. "Switchover" is handled by version list item with end user selections that do not require workspace admin paired with DCA lock logic. The only real drawback being extra line items in modules for Actual and Forecast but this also enables a point of comparison of Actuals versus Forecast that is not possible with standard Switchover.

  • -> Ability to select versions as a list formatted line item for use in lookup statements.
    Another vote for this. Having this will help even in big sized versioned modules avoiding additional modules for variance analysises.

  • Seeing that this request is 3.5 years old, maybe Anaplan could at least update the training and demos to emphasize that the native versions functionality is a legacy feature that is no longer actively supported.  There is almost no situation where the native versions are the right choice long-term, but that's what's sold to the client because it's faster to demo.  By the time the new customers realize the inflexibility of the native versions, they've incurred a lot of technical debt.

  • @clark.earl 


    Actually, native versions is not a legacy feature, it is being used in many models.  And I strongly disagree with your assessment that "there is almost no situation where the native versions are the choice."  I suggest reading this link as well as this link to understand the differences.  



  • @rob_marshall 

    The point of the discussion is, that besides all the feature native version have, the limitation of not beeing able to use them as list formatted line item, renders them nealry unusable.


    If there has been no substantial change to native versions, despite the fact that the lag of one feature is causing massive modeling problems in nealry every project, someone can come to the conculsion, that this feature is no longer in active development.


    To your links: first link outlines the discussed limitation but not its implication, last edit 2020. Seccond link is newer, great technical detail, makes me want to use native version for technical reasons, but does not relate to the discussed problem.

  • @OliverIbach 


    The point of the discussion is the need for Native Versions to be used as line items list formatted.  I have no issues with that and have been begging for that functionality for nearly 8 years.  So no issues with that at all.  Now the other hyperbole that you and others are stating that Native Versions are nearly unusable is what I have an issue with as it is simply not true.


  • Agreed with rob : NAtive versions have still a lot of usability albeit their downsides regarding not supporting other lists features (subset / list formated options...) (which starts to really become an issue when trying to implement the connected planning honeycomb road)

    Most notable coming to my mind is that versions are on different blocks (same as time elements) and do not account to the calculation engine limit. This advantage can undertandably be marginal for some use case with low / middle cells counts and clearly be offset by the native versions limitations...

    So as others stated before better than myself : version list formatted please ^^

  • Following

  • Can we get someone from product teams to provide updates regarding this highly requested piece of feature ?

    We used to have people like david Smith regularly updating people requests in the past, but since 2020 or so it seems we are cut from product mgt folks commenting what is feasible, whats planned on the tops most popular requests.

Get Started with Idea Exchange

See our Submission Guidelines and Idea Evaluation Criteria, then start posting your own ideas and showing support for others!