Ah, I've run into this exact one — dependent choice fields rendering blank in lists while working fine on the form. It's a frustrating, subtle one, so you're not missing anything obvious.
The short version: this is a known limitation of how lists (and especially the Workspace/Agent data grid) render dependent choices, not something wrong with your config. On a form, the field knows the dependent value (the Organization) and can resolve the right choice label. In a list cell, the renderer often doesn't carry that dependent-value context, so it can't match the stored value back to a sys_choice row and just paints blank. That's also why flipping off the "Use dependent field" dictionary attribute makes them reappear — without dependency it only needs the value, not value + dependent_value.
A few things worth checking / trying, roughly in order of least-invasive:
First, confirm the data side is actually fine (it almost certainly is): open a sys_choice record for one of these and check that both the value and the dependent_value exactly match what's stored on the record, including case. A whitespace or case mismatch on dependent_value will make it resolve on the form but not in lists.
Second, the cleanest workaround I've used is to keep your dependent choice as-is for data entry, but add a separate read-only string field that mirrors the label, and show that in your list/workspace views. A before insert/update Business Rule is the most reliable since it covers list edits and imports too — something like:
(function executeRule(current, previous) {
if (current.u_role.changes()) {
var label = current.u_role.getDisplayValue();
if (label)
current.u_role_label = label.toString();
}
})(current, previous);
Then put u_role_label on the list/workspace view instead of u_role. Not glamorous, but it's stable and survives upgrades.
One caveat: I'd test the mirror approach in a sub-prod instance first, and double-check getDisplayValue() returns what you expect for the dependent choice in a server context — if it ever comes back as the raw value, you can resolve the label directly off sys_choice filtering by name (the table), element, value, and dependent_value.
Give the data-check a look first — if the dependent_value matching is clean, the mirror-field route should get your lists looking right without disabling dependency. Happy to dig further if it's still being stubborn.
