In the Importing Data Modules Activities for Employee Details, I'm having issues matching the employee names with the source. It does not recognize the employee name in the 2nd tab ( "#E2 Employees") and therefore does not match the names. See Screen Shots.
This is because this is a numbered list vs a standard list. Because of this, the system will generate an ID for the name and you will import off of the code, while using a display name property for end users to see. Re-watch the Microlesson on importing into lists, it will discuss this exact issue under Importing Errors.
So this response explains why the problem exists, but I don't see how it rectifies the issue. If the module imports can't map the data to be imported automatically to numbered list display names, it seems to me to be a strong disincentive for using numbered lists.
Honestly, I'm having trouble really seeing the value proposition of Anaplan-managed numbered lists at all. While it's certainly valuable to have guaranteed uniqueness in one's key/code, It's often desirable for that unique key/code to not be a simple serial number starting from 1. the micro-lesson sets the code to the SKU number, and that provides enough uniqueness on its own. Systems like SAP can assign unique numbers to new master and transactional data entries (e.g., inventory material numbers and sales order numbers, respectively) within a range while still being random enough to make fraudulently fabricating a valid number difficult for social engineers/hackers.
I'd love to hear someone succinctly sell me on the value Anaplan-style numbered lists, because being unable to import data in situations like what the OP (and I) encountered would be daunting indeed if the list were an order of magnitude or two larger.