There are two pieces of context worth establishing:
- When an item is chosen in a lookup, I’m choosing a specific object by reference. I expect my reference to remain intact unless I actively change it.
- A lookup column can have a filter defined in its Item Settings to restrict which rows are displayed as options in the UI. It’s a super useful feature, especially when there are multiple rows in a table with the same display name.
Changes to the Item Settings filter should change which items are suggested in the UI. They should not change the object lookups themselves.
When the Item Settings filter is changed all of the lookup values get reevaluated. But rather than reevaluate them by some underlying ID (i.e. by the actual reference), they’re reevaluated by display name.
So if there are multiple rows with the same display name in the foreign lookup table, all of the references now point to the first one int he list (which is often the wrong one) causing data to be lost in an unexpected way.
I don’t know how often this happens to other people, but it’s happened to me several times. I was previously confused about what was going on and only now in retrospect understand why I kept having references to the wrong items popping up. Given that it causes actual data loss in a very hard to identify and unexpected way, I think this is worth fixing.
I’ve recorded a video showing it in-action. Please excuse my voice I’m not much of a voiceover talent.