Question
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"
},
Answer
When we look at the entity, we see OrgCom attributes, 41SEhKv2S and 41SEhKVSu and we find the belowsingleAttributeUpdateDates
for 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.
Comments
Please sign in to leave a comment.