Anyone have any good notes on the technical differences in List entity types (List, Group, ..)
I spot issues in various ways, eg Update List processes create lists of type List, but creating a List directly via the List form can only create as type "group". There are then constraints imposed - eg a Update List process can not update a list of type Group, though there should be no issue with the compatible data structures.
Am in the middle of reverse engineering this but if anyone has any shortcuts, very happy to add to useful google search hits on this subject!
List: This type is used to extend the list schema using Extension data. In short, this enables us to have the extra column to ootb table.it can be the recipient or any adobe schema.
Group: This type is used to store a relationship with only recipients and you can only use recipient columns or already extended column in nms:rcpGrpRel table, No flexibility to add extra columns on runtime.
Rest two type cannot use Register and unRegister method as defined in nms:group.js
I observe and validate the same. Clearly, the groups table is, like other parts of neolane architecture, a resuable container 😉 the @type field seems to be mostly for filtering the schema for these various use cases. The question is mainly why type List vs Group, what is the functional intent to create the two types? I had to do some magic the other day leveraging List objects and due to these differences, major pain in the ass to move between instances (legacy groupid values vs reference to internal names), and reuse lists via Update List processes in different workflows.
But yes I will raise a ticket and post any insight I can get via engineering.