Substate values not visible in list view
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
In the 'alm_hardware' table, we have a field caller 'Substate'. This substate is dependent on state field, and both these fields are taken from 'alm_asset' table. Actually, hardware table is extended from asset table. Now the problem is for some of the records, the substate field doesn't show any value in list view. If I open that record, the value is present.
It seems like this issue started happening after the instance was upgraded to Australia. I looked into the choices for substate and found mostly it is on asset table, and a few are created for hardware table too. Now for one specific state, all substate values are created on hardware table, and mapped correctly, which is visible in list view as well. Those options which are partially created (on hardware table), have problems being visible. I figured one way to solve it is to create all the mappings in hardware table.
The other thing I noticed is that some of the substate values shown in list view are the actual values and not the label, and searching about this, I found this article: Substate field on list view of Harware (alm_hardware) or Asset (alm_asset) is showing the choice val...
So alternatively, I could also deactivate/remove all choices which are not on asset table which should fix my issue as well.
I couldn't find anything else online and before proposing a solution, I want to ask the community if anyone have a potential root cause and solution for this issue or if the solutions I figured are good? I have admin access in the instance and I can edit the substate values in list view too. So, this isn't an ACL issue. Any kind of help is very much appreciated.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
53m ago
When choice lists for dependent fields like Substate are split between parent (alm_asset) and child (alm_hardware) tables, ServiceNow's dictionary evaluation breaks post-upgrade, causing list views to display raw backend values instead of labels or fail to render options entirely.
The best practice I feel is to centralize all choice configurations exclusively on the parent alm_asset table and delete or deactivate the duplicate choices on the child alm_hardware table. Afterward, update any affected records to point to these centralized parent choices, which will permanently resolve both the visibility bugs and the value-versus-label rendering issues in your list views.