From what I have read and seen Numbered Lists are used predominantly to reduce sparsity, i.e. when you have a lot of cells in two dimensions that are not ever going to contain data. My question is however, what other uses are there for numbered lists? Are they used to manage a situation where there are duplicate names in a list for example?
Solved! Go to Solution.
Numbered lists have a host of use cases. Here are a few off the top of my head:
1. To accomodate descriptions (aka Display By) values > 60 characters. Non-numbered lists have a limit of 60 characters for the NAME value. By using a numbered list, Anaplan assigns the NAME as a #number, and then we leverage CODE and a Display By property to manage how end users interact with the numbered list. When folks view a Display By (text) property in a numbered list, there is no limit to the length. We run into this a lot with Account, Employee, Vendor, and other similar master data.
2. To accomodate duplicate items, like in your example where we often combine dimensions to reduce sparsity (and, often, improve end-user experience). The duplicates technically aren't duplicates... they just appear that way to end users. On the back end, Anaplan sees otherwise duplicate numbered list items as completely separate & different.
3. Note that numbered lists can only have one level. When using parent/child lists, most folks use numbered lists for the child list(s) (although its not technically required). We do this because, often, the CODE & Display By are defined & set via some form of automation.... and you can't do this without a numbered list.
Would like to comment on the statement "When using parent/child lists, most folks use numbered lists for the child list(s) (although its not technically required)". I believe it is best practice to only set child (leaf) lists as numbered lists and not to set parents as numbered lists as much as possible. To best illustrate the reason I'd like to provide an example. Bear with me as the explanation can be slightly long. We have the following list hierarchy:
L3 Business Unit
L4 Cost Centre
Each country has the same set of business units. E.g. Energy, Industry, Mining.
Since we did not implement L3 Business Unit as a numbered list, we had to name business units in each country unique.
FR Energy, FR Industry, FR Mining
UK Energy, UK Industry, UK Mining
We needed to implement selective access on the hierarchy above as we had instances where a user would only be responsible for a business unit across all countries. So we would have to grant access to FR Energy, UK Energy, etc ...
So when the user went to a dashboard, they the selectors they had available was
Had we implemented L3 Business Unit as a numbered list, instead of using FR Energy and UK Energy as the description for the list item we would have used the description "Energy" for both FR and UK instances. If that happened the user would have gone to the dashboard and found the selectors they had was
The user is now unable to easily identify which one is the FR against the UK business unit. It is possible for same issue to occur at the leaf lists as well but is far less confusing when it happens at the leaf list than it is at the parent lists.
Primary reason for numbered list design usage: reduce sparsity. Other benefits: +60 CHS label names, create actions, derive labels formulacially.
If you want to watch a video on how numbered lists can be created and uses, go to https://www.youtube.com/watch?v=PXun8oLG5Ac&list=PLat1JW8TS3RlhZ2PF_vtoqeRBX7Jcy6JF&index=3
In additiona to above mentioned use cases numbered list if properly designed and have a property to identify it with regular list members we can design our models and reduce the size significantly but have the same information in our hands.
Further it would be very easy to lose control over the numbered list if not properly used and if you just go an adding numbers, its highly advisable to have a validation check with numbered lists.