Choice lists
Managing choice values, dependent choices, choice list specifications and the mistakes that cause blank fields after an upgrade.
Managing choice values, dependent choices, choice list specifications and the mistakes that cause blank fields after an upgrade.
- 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.