Get choice field options dynamically

Choice field options live in sys_choice, not on the field definition itself. This separation means you can't just inspect a GlideRecord to get choices — you have to query the choice table by table name and field name. The platform stores choice values as strings even when they represent integers (like state fields), and empty choice values represent the null option. Most developers miss domain separation impact and inactive choice filtering, leading to incomplete or restricted choice lists in production.

When to use this

• Building dynamic forms where choice options depend on other field values
• Validating choice field values in Business Rules or ACLs before database commit
• Converting choice values to display labels for email notifications or reports
• Populating reference field choice lists based on current record context

When NOT to use this

• Don't use this in client scripts — use GlideAjax to call this server-side pattern instead
• Don't query choices repeatedly in loops — cache the map and reuse it across iterations
• Don't use this for system choice fields that change frequently — they may be computed dynamically
• Don't ignore domain separation — choices without domain filtering will be incomplete in domain-separated instances

Key behaviors and gotchas

• Choice values are always strings in sys_choice, even for state fields that use integer values like '1', '2', '3'
• Empty value field represents the null choice option, not a missing choice definition
• Domain separation restricts choice visibility — always filter by getDomainIDs() in domain-separated instances
• Inactive choices (inactive=true) still exist in the table but shouldn't appear in UI choice lists
• Choice sequence determines display order — always order by sequence then label for consistent results
• Extended tables inherit parent table choices unless overridden with table-specific choice records