Why would the nested attribute sort order change after an update that did not impact any of the nested attributes?


When we do a partial load for an existing profile in our tenant, the attributes which are not of the load, are also getting affected and behaving strangely. In this example, when we do a partial load for some of the name attributes, the order of the communication values changes every time we perform the load. We have identified the same for other nested attributes as well. The attribute ordering for all of these attributes is the default option which is LUD. 

As far as my understanding of LUD goes, any value coming from a crosswalk with the latest update date will be given priority. But in this case, the crosswalk for all the values is same and hence the order should stay the same. Is there something in the physical configuration that is causing this? Wil be really helpful if we can figure out what's causing this behavior. 

Before update:


After update:



Nested attribute configuration


                "label": "Communication",
                "name": "OrgCom",
                "type": "Nested",
                "hidden": false,
                "important": false,
                "system": false,
                "required": false,
                "faceted": true,
                "searchable": true,
                "attributeOrdering": {
                    "orderType": "ASC",
                    "orderingStrategy": "LUD"


When we look at the entity, we see OrgCom attributes, 41SEhKv2S and 41SEhKVSu and we find the belowsingleAttributeUpdateDatesfor the attributes


"entities/32tDDlgi/attributes/OrgCom/41SEhKVSu": "2022-09-01T06:05:10.088Z",

"entities/32tDDlgi/attributes/OrgCom/41SEhKv2S": "2022-09-01T06:05:10.088Z",

If the LUD is the same for the two nested attributes, the attribute sort order for those nested attributes is not guaranteed.  





Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.