Hi Miruna,

The use case is similar to the examples shown in the images. We often have fields such as color names, item names, or worker names - where multiple entries may share the same name but have different IDs.

For lookup purposes, it's more user-friendly to display the names (rather than the IDs) in a drop-down list, as names are easier for users to recognize and remember. However, when we have duplicate names with different IDs—each representing a distinct row with different properties—the drop-down now only displays one of the repeated names, effectively hiding valid data entries from the user.

If we use IDs instead of names, the drop-down will show all unique rows correctly. However, managing lookups by ID is not practical for end users, as IDs are not meaningful or memorable to them.

This recent change in behavior is impacting processes that rely on presenting repeated names in the drop-down while preserving their underlying differences. We had previously used the ALL quantifier specifically to retain those duplicates, and would appreciate if there’s a workaround or option to restore the original behavior.

Hi Louis,

Thank you for your time on this question. As shown in the example, I am using a Table (Image 2) that includes one column for IDs, which are unique for each row—even when rows share the same name. This is because the table also contains other columns with different properties for each duplicated name.

I am not using the drop-down panel to manually populate the fields. Instead, the drop-down is populated through a lookup query rule linked to the table.

You're right that assigning different values to the labels would work, but in this case, using the drop-down panel to populate it will become unmanageable due to the volume—nearly 3,000 names, many of which are similar.