Choice lists
Quick answer
Managing choice values, dependent choices, choice list specifications and the mistakes that cause blank fields after an upgrade.
Key takeaways
- Keep values stable, edit labels freely
- Use dependent choices instead of client scripts for simple filtering
- Add choices at the child table, not on task
- Inactive is better than deleted when a value is retired
How choices are stored
Each option is a sys_choice record with a table, element, label, value and sequence. Label is what users read, value is what scripts and reports use. Once records exist, changing a value orphans data, so change labels and leave values alone.
Dependent choices
Set a dependent field on the dictionary record and populate the Dependent Value column on each choice. Subcategory depending on category is the classic example. The client filters options as soon as the parent changes, no scripting needed.
Choice list specification
The dictionary field Choice controls what happens with values that are not in the list.
- Dropdown with none: adds an empty option
- Suggestion: users can type a value that is not listed
- Dropdown without none: forces a selection, useful for state fields
Inheritance on extended tables
Child tables inherit parent choices. Adding a choice on task adds it everywhere, which is rarely what you want. Add choices on the specific table, for example incident, so other task types stay clean.
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which column drives dependent choice filtering?
- A. Sequence
- B. Dependent Value
- C. Hint
- D. Language
Show answer
B. Dependent Value
Dependent Value matches the value held in the parent field.
Safest way to retire a choice?
- A. Delete the record
- B. Rename the value
- C. Set it inactive
- D. Remove it from the form
Show answer
C. Set it inactive
Inactive keeps historical data readable while blocking new selections.