Anaplan Data Hub - Numbered vs regular list

I am in the process of creating a Data Hub, where we will be getting multiple files to create lists in the DH. I need to consider creating the flat lists as either numbered or regular list. 

For the lists which have member names longer than sixty, I would create a numbered list where I would make use of the Display Name properties. However, with lists that have less than sixty, can you suggest any other advantages of using numbered list ?

In case of lists that have members names shorter than sixty, do you recommend using regular list of numbered list?

I have heard that are issue mapping numbered list if we need to send fact data across models.

Any suggestion would be appreciated.

Tagged:

Answers

  • Hey @khoonks,

     

    The way to think analyze whether to use a numbered list or regular list is an interesting question. 

     

    The way I like to think about it is looking at the nature of the data and the architecture vision you have in Anaplan. 

    My default is using a regular list. The exception is to use a numbered list. Here are some things to think about when seeing if you need to use a numbered list: 

     

    Does your data contain Employee Names for example where you may have 2 people that could coincidentally have the same name (i.e. 2 employees named John Smith)? 

     

    If so, then having a Numbered List is valuable in this scenario so that each employee is imported separately even if they have the same name. General lists allow you more flexibility in your modeling and system modules. Here is another previous thread you may find useful too. 

     

    https://community.anaplan.com/t5/Anaplan-Platform/When-not-to-use-Numbered-Lists/td-p/91735

     

  • @DaanishSoomar - I dont have employee names as such, however, we have names in the source system which are longer than sixty characters long, and since I cannot add them as members in Anaplan lists, I was thinking of using the numbered list so that I can use "display name" property. 

    I would prefer the regular list, however, beucase of the limitation, I was thinking about numbered? Any suggestions?

  • @khoonks -

     

    Okay got it. Are these names concatenated? Or are they truly inherently longer than 60 characters? 

     

    If they are concatenated, you could refer to the example given by @JaredDolich here-  https://community.anaplan.com/t5/Anaplan-Platform/Character-limit-of-60-on-Anaplan-code-Possible-solution-to/td-p/63985

     

    Otherwise, you may be right in that you need to use a numbered list. Unless others see another way.

  • @khoonks 

    Awesome question and challenge!

    I agree with @DaanishSoomar on his point - if there is any way you can reduce the names to an identifiable ID, like employee ID, then you will be better served in the end. Using a numbered list will complicate matters for you later on if you try to do delta loads because you'll never really be able to efficiently map your delta values to the correct system generated ID from Anaplan if you use a numbered list.

    I guess what I'm trying to say is try to avoid using a numbered list and most certainly avoid using a sequential number as a unique identifier if you can. I know it's tempting because it works 100% of the time but you'll find later that it's terribly inefficient and a burden on the memory allocation. Even worse, if you have to delete the list and rebuild it each time you load the data. Deleting turns on the logging and slows down the import.

    Anxious to hear what you decide to do!

  • @JaredDolich @DaanishSoomar -

    Thanks for the response.

    Some of the source systems (as you know) allows longer character limits and so the alias are very long which would be used as members in Anaplan lists. However, as Anaplan has the 60-character limitation, I was asking about the numbered list, however, I am not too much in favor of numbered list because as you guys have mentioned (the issues down the line). Will need to find ways to limit the alias to 60 and / or use numbered list very sparingly.

    Thanks again.