Change a List Lookup value or not?

Would it be enough to change a list lookup value for LL called nsCoxManufacturerCode eg. from FRD to FD?

Or would you have to add the new value FD and then delete FRD.

Is there a process / tool to do this? I have a feeling that I would have to check logic blocks testing against the old value (FRD). Can someone confirm?

Hi Ed!

Unfortunately no, we do not have a process/tool for this. The original assumption was that the Values would be pretty static and it’s typically the Descriptions that change. If you are a Nextworld customer or partner, you can work with your system administrator to submit an official enhancement request with customer support. Include a link to this post in the support ticket. If you’re not a Nextworld customer, keep an eye on release notes. We’re always making improvements.

In the meantime, you’re right, you must double check all logic and data mappings to make sure they’re referring to the new value, and you’ll need to run some transformative logic to handle all records that hold the old Value; that is not handled automatically.

1 Like

My recommendation varies based on how far down the release pipeline your ‘bad’ List Lookup value has already traversed and the impact of leaving the old value in place.

If your List Lookup has already traversed the pipeline to prod and you are reasonably confident that some data exists in prod with that List Lookup value then this is how you remove it completely:

  1. Add your new value. Deprecate the old value.
  2. Add new logic branches for the new value, not removing the logic branches for the old value. Where used in Developer Studio will be of assistance to find references.
  3. Create a data transform that converts the old value to the new value in any pre-existing records.
  4. Deploy ^ and run that transform in all downstream environments.
  5. Remove logic branches for the old value. Remove the old List Lookup value if possible. Release management rules about previously released things may prevent you. I don’t remember.

Alternately, if true removal of the value from pre-existing records is less of a concern then I would stop after step #2 and leave this backward compatible code in place indefinitely.

Alternately again - if this has not yet traversed the full pipeline or you don’t care about the pre-existing data you can do some set of these steps to the target environments the ‘bad’ List Lookup Value has reached.

2 Likes

Thank you Brendan and Kendra. I’ll follow your lead.

1 Like