I would update your SmartObject to do the legwork of getting the display value for the list, so it can just display it as if it were a normal property.

Hi There,

Thanks for the reply. Apologies for my ignorance but I am not exactly sure how to go about giving the workload to the SmartObject correctly. I have tried to fetch display values when getting the list for my ListView and map it to a column but was unsuccessful. I also looked into expressions to see if I could fetch a display value field from that but was unsuccessful. I don't want to save the display field as an extra field in my referenced SmartObject for the sake of that display value being changed somewhere else in the process on the original SmartObject, so I want to be able to fetch that display field at runtime when loading the list. 

Could you possibly provide some direction on how to achieve this by giving the legwork to the SmartObject or perhaps can reference me to an article, sample package or community thread that could steer me in the right direction? I have tried looking for content on the matter but could not find anything

I was suggesting that you add the display field as an extra field in your SmartObject - I think that is the best way to handle this situation. If someone else that consumes this SmartObject tries to change the Display field, it won't really have an effect as it isn't mapped to an update function. It might be a little confusing, you can perhaps name your display field on the SmartObject as "Read Only" so other consumers understand its intent.

Thanks for the reply. I did think about storing the display property in the consuming SmartObject as an additional property but this could potentially cause stale data over time.

An example would be if I had two SmartObjects, one called 'Months' and another called 'Requests' and the Requests SMO consumed the Months SMO. If I store both the 'Months' primary key and display value as two separate properties on the 'Requests' SMO then I am saving the current Months display pattern/standard. This means that if the current pattern of naming months is {Jan, Feb, Mar,....} it would store this pattern. If down the line the process requires this pattern to be changed to {January, February, March,....} only new Request SMO's will adopt the new pattern, and all old Request SMO's will hold the stale pattern for months. If down the line it changes to {01, 02, 03, ....} there will be two levels of stale data in old Request SMO's. If one of the months were spelled incorrectly and only noticed a week in, all SMO's for that week will need to be manually updated for records which use the misspelled month. So this approach can cause a lot of overhead which I would prefer to avoid.

I have however managed to come up with two approaches to this problem, should it help anyone else trying to mitigate stale data. The first is to create associations between the two SmartObjects in the SmartObject builder, and then on your list configure a 'List Display' control column and you will be able to configure a dynamic display value. This introduces possible performance concerns, so you should test it out to make sure it does not cause any delays in load time.

The other is to create an Advanced SmartObject and create a SmartObject method that queries a list of Requests as well as a list of Months and perform a join to create a new SmartObject that has the dynamic display value. This approach allows you to avoid associations if you would like to do so.

I have reached a use case where storing the display name as a property was the best solution, due to the performance impact the above two introduced. Trying to use the user FQN stored to request a users name through the UM user management, connecting to Azure Active Directory caused long loads. I accepted the potential stale data to give the users a better experience then viewing the user FQN, but still display the FQN as an additional property they could refer back to if the display value ever does go stale.

I am not sure if there are any other approaches to tackle this problem, but these are the ones I am aware of thus far.