Production list item protection



We are in the final stages of an implementation and are running into issues related to marking lists as production data.  The problem is that over the course of development many list items have been referenced in line item formulas, so the system prevents these lists from becoming production data.  The workarounds suggested in other community posts, such as using LOOKUP instead of SELECT, have not worked.  If anyone has any experience with this problem or suggestions I would greatly appreciate any help.


Thank you,



  • HI, 


    The workaround would be to make those selections dynamic. 


    To identify where those items are referenced (you can go to general lists, select the list you want to check and look at "Reference in formulas"). Then, create a module (no dimensions) and Line items - list dimensioned - and pick up the element from the list you refer to. Therefore, instead of referencing the list item directly in the formula you lookup that specific Line Item which was created in a module. 


    In this way, you remove every direct reference to your list elements

  • Hi,


    I think this can help:

    To make it easier for the next implementations, you should set up the lists as production as soon you create them.




  • Thank you for the feedback.  Do you know if using the PARENT function on a list will prevent marking it as production data?

  • No, the PARENT function will not prevent marking a list as production as you are not referring to a specific item (that is the case of the SELECT instead).




  • How about FINDITEM?

  • Also FINDITEM works fine with Production List as you search a correspondence of a text in a list (again, no reference to a specif list item).
  • @a.dilieto ,


    I think I understand why you are setting all lists for Production Data at creation (so no hardcoding or select statements can be used), but this can be very dangerous especially in a Deployed model.  If you remove the the production data boolean (making it a regular list) and then sync to production, then all data in the production environment tied to that list will be deleted.  The reason for this is during the sync, the list in Production will be wiped cleaned (deleted) and the members in Dev will be inserted.  Even if the the members with the exact same codes are used in Dev as well as in Production, the system doesn't understand that and simply wipes the list out.


    So, instead of making every list a Production Data list, it is best to understand what the list will be used for (does it need to be updated in a Production environment) or is a static list (Active vs. InActive)?.  If the list will be updated via actions or user involvement, then it will need to be a Production Data list.  If it is static, it should be a regular list.


    Hope this helps,


  • Hi Rob,

    Indeed, I was not clear but I meant setting to Production the lists that should be Production (not all).


    Just to clarify on  "Formula protection"


    What is it?

    • Hard coded references to a list member
    • SELECT, IF ITEM(xx)=, P1 Product.Cars
    • Top Level Item is OK as that is structural (you cannot change the Top Level in a Deployed model)
    • You can have CODE(ITEM(P1 Products))=, or NAME(ITEM(P1 Products)) because that is not referring directly to a list element.  Still not good practice though!!


    • In standard mode, you will generate a rollback if you delete/amend the list member
    • Anaplan doesn’t not allow end users to generate a rollback
    • In Deployed mode, a "Production" list allows end users to delete/amend the list, so Anaplan “protects” the list against this

    Good Practice

    • It is bad practice to have hard coded references


    I hope that helps clarify things


  • Hi! I am using this extra module with list-dimensioned Line item to reference a Production list. But I need to reference the item on Level 1, and the list is hierarchical with no Top Level Item. Like for example, we have Germany (level 0) and France (level 0) but I need to reference Europe (level 1). The formula works but gives 0 as a result. Do you have any ideas how to deal with such a case?

  • @YuliaL 

    Is the list in question a non-composite list, as in are levels 0, levels 1, etc. all part of the same list?


    Is suspect it is because of your point about returning zero (a know issue for LOOKUP on non-composite parents)


    An alternative would be to create a composite lists and the LOOKUP will then work, but if that is not feasible, then this article might help



    It is a little involved, but does get around the issue of production list formula protection for non composite lists


    As an aside, I am working with engineering to resolve the issue above, so that the formula will return the value


  • Thanks David, after your comment I've realised that we have exactly this module to build flat hierarchy for other things. So I used that hierarchy instead and it worked fine:).

  • @YuliaL 

    Good to hear