When not to use Numbered Lists?

michael.jones

Given how flexible numbered lists are, is there a reason why I should not make all lists in a model 'numbered'?

Accepted answers

JaredDolich

@michael.jones

Two reasons that come to my mind immediately:

Numbered lists essentially reduce you to one primary key, the code. This can also present some challenges when moving system module properties of that list from one model to another because you have to reference the code. If the code is a made up value for the purposes of Anaplan then it really is not meaningful. It also then requires you to identify the system generated ID from Anaplan if the code value needs to change and is synchronized with another model. Good example would be Data Hub to Spoke application. If the code changes, how else would you know how to find the list value that changed so you can edit the code? Otherwise, you'll just be adding another list item.
If you need the ability to create list items from a dashboard you no longer need to use a numbered list. You can create forms in the new UX.

I remember reading a good debate between @rob_marshall @DavidSmith and @Misbah whether numbered lists are even needed. I'll see if I can find it. They may have some additional input for you.

DavidSmith

@michael.jones

I actually look at it the other way - Why would I use a number list? - In most of my Anaplan modelling I use normal lists. Even for "combination" lists as generally you are in control of the code and name, and the complexity around moving data between modules/models is a problem, as @JaredDolich outlined

So I only use Number lists when I need to take advantage of the specific features (display names, assign, copy, delete branch etc.)

Going forward, I'd prefer that we unify lists and only have 1 type, so taking the best bits of functionality from both

David

All comments

JaredDolich

@michael.jones

Two reasons that come to my mind immediately:

Numbered lists essentially reduce you to one primary key, the code. This can also present some challenges when moving system module properties of that list from one model to another because you have to reference the code. If the code is a made up value for the purposes of Anaplan then it really is not meaningful. It also then requires you to identify the system generated ID from Anaplan if the code value needs to change and is synchronized with another model. Good example would be Data Hub to Spoke application. If the code changes, how else would you know how to find the list value that changed so you can edit the code? Otherwise, you'll just be adding another list item.
If you need the ability to create list items from a dashboard you no longer need to use a numbered list. You can create forms in the new UX.

I remember reading a good debate between @rob_marshall @DavidSmith and @Misbah whether numbered lists are even needed. I'll see if I can find it. They may have some additional input for you.

DavidSmith

@michael.jones

So I only use Number lists when I need to take advantage of the specific features (display names, assign, copy, delete branch etc.)

Going forward, I'd prefer that we unify lists and only have 1 type, so taking the best bits of functionality from both

David

Misbah

@michael.jones

Yes, many reasons not to make your list numbered list (let's not talk about all). If you have duplicate names but unique codes in your list, that should be the right call for you to make it a numbered list.

All those 4 actions that @DavidSmith mentioned, you will have to use Numbered lists. I personally am not a huge fan of numbered list, to me general lists are more flexible.

Misbah

swatikhedkar

I have a level 2 P&L list... see it as a sub group under main p&L list. the inputs happen at P&l level 2 list. this list is created from actuals that come in. We made this list as normal list because of the nature of this list as we didnt wanted a P&l level 2 item with different code and same name to be created. we recently got such case and a warning was thrown. what is ur take on this? should list like P&L sub group made numbered list ? One more issue i see it in making numbered list is then the user will not be able to identify which item it was with same name as we dont display code on DB and difficult to remember code and search .

Quick Links

Can you help?

Unanswered questions

Excel date format for February 2030, 2031 and so forth don't align with Anaplan format
Hello, I’m running into a recurring issue when importing CSV files into Anaplan, specifically with dates in February for the years 2028, 2029, and beyond. Here’s what’s happening: In Excel, the date format is set to Custom (e.g., 2/26/2025). When imported into Anaplan, the date is interpreted as 26-Feb, where: Month = Feb…
RANKCUMULATE not working when adding additional dimensions to module
I have an issue where I am getting the expected result from RANKCUMULATE when using one dimension, but when I add an additional scenario dimension to the module, it doesn't calculate the way I'd expect. Here are some screenshots to explain the case: Module 1 - calculates cumulative total for list items in list "Age"…
Introducing Anaplan API Python SDK
Hey everyone, I wanted to share the Anaplan Python SDK with you. It's a Python Library that wraps all Anaplan APIs and makes it easier to interact with Anaplan programmatically. It is mostly designed with Data Integration Scenarios in mind, but it does support all APIs including ALM, SCIM, Audit, and Cloud Works. Please…