Read a display value vs stored value from a choice field

Choice fields store integer values but display human-readable labels. Most developers instinctively compare against what they see in the UI ("New", "Resolved") rather than the stored integers (1, 6). This creates brittle code that breaks when administrators change choice labels — something that happens regularly in large enterprises. The platform provides getValue() for stored values and getDisplayValue() for labels, but the distinction isn't obvious until your perfectly working script suddenly fails after a choice list update.

When to use this pattern

• When building conditional logic based on choice field values in server-side scripts
• When you need both the database value for logic and the display value for logging or notifications
• When writing scripts that must survive choice label changes by administrators
• When working with state fields, priority fields, or any choice field that drives business logic

When NOT to use this

• Don't use getDisplayValue() for comparisons — use the Choice API or hardcoded integers instead
• Don't use this pattern in client-side scripts — g_form.getValue() and g_form.getDisplayValue() exist for forms
• Don't use getDisplayValue() in loops over large datasets — it's slower than getValue()

Key behaviors and gotchas

• State field integers: New=1, In Progress=2, Resolved=6, Closed=7 — these are consistent across instances
• For reference fields, getValue() returns the sys_id while getDisplayValue() returns the display field value
• Empty choice fields return empty string from getValue(), not null — always check for both conditions
• Custom choice fields use sequential integers starting from 1, but gaps can exist if choices are deleted
• getDisplayValue() respects language translations — a resolved incident shows "Résolu" in French instances
• Domain separation affects choice lists — the same stored value can have different labels across domains