Hi Liming,
Short answer: not out of the box. In workspace the column header comes from the field label (sys_dictionary / sys_documentation), and the list component just renders that - it has no awareness of what filter is currently applied, so there's no config switch that says "when State = Failed, call this column Root Cause".
A few ways people usually handle this instead:
1. Separate lists per state. Create two saved list views / list menu entries (Successful, Failed) each with its own fixed filter, and rather than re-labelling the same field, expose two different fields (or two calculated / display fields) that carry the right label. This is the cleanest from a maintenance point of view and users still feel like they're clicking one list.
2. Different list views with label overrides. You can override a field label per view (sys_documentation with the view set), so a "failed" view of the operational vulnerability list could show Vulnerability Status as Root Cause. The catch is that the view is chosen when the list is opened, not when the filter changes.
3. Custom list in UI Builder. If it really has to react live to the filter, build the list on a UI Builder page with a data resource whose query is bound to a state control, and set the column labels through a client script / property that reads the same state. That gives you full control but it's a custom component you'll need to maintain through upgrades.
From your screenshot this is the Operational Resilience Workspace (Operational vulnerability - All operational vulnerabilities list), which is a UI Builder based workspace, so option 3 is technically possible there - but before going that way I'd check with the business whether the real need is "different labels" or actually "different columns for different outcomes". In most cases I've seen, option 1 solved it with far less effort.
Which release are you on? Happy to be more specific.
Macki | Deloitte AU | Engineer Lead
