› CIS-DF Hub › Part 6 › Field Validation & Choice Lists
⬡ Part 6 · Topic 2

Field Validation & Choice Lists

Consistent, validated data starts with the right constraints on every field. Learn field-level regex validation, how choice lists store and compare values, dependent picklists, and when to use a lookup table instead of a choice list.

📋 5 sections ⏱ ~16 min read 🎯 ~8% exam weight 🏷 Data Quality
Section 1

Choice Lists — How They Work Under the Hood

A Choice field presents a dropdown of options on a form. These options are stored in the sys_choice table — one record per choice option. Each choice has four key attributes:

  • Table — which table this choice belongs to
  • Element — which field name on that table
  • Label — what users see in the dropdown ("High," "New," "Pending")
  • Value — what gets stored in the database ("1," "2," "3")

The label and value are deliberately separated. This allows ServiceNow to store compact values (integers, short codes) in the database while displaying human-readable labels in the UI. It also allows the label to be translated for different languages without changing the stored value.

⚠
Exam Trap — Always Use Values in Conditions Business Rules, Client Scripts, and GlideRecord queries must use the stored value for choice fields. The Incident state field stores 1 for New, 2 for In Progress, 6 for Resolved, 7 for Closed. Writing if (current.state == 'Resolved') will NEVER be true because "Resolved" is the label, not the value. Always use current.state == 6.
Section 2

Dependent Choice Lists

A dependent choice list filters the options of one field based on the current value of another field. The classic example in ServiceNow is Category → Sub-category. When you select "Software" as the Category, only Software-related subcategories appear. When you select "Hardware," only Hardware subcategories appear.

This is configured in the choice records themselves: each Sub-category choice record has a Dependent value field specifying which Category value it belongs to. The field also needs to be configured in the dictionary with a Dependent field pointing to the parent (Category) field.

📘
Core Concept — Dependent Choices Are Still Choice Records Dependent choice options are still rows in sys_choice — they just have an additional "Dependent value" populated. You manage them the same way as regular choices: navigate to System Definition → Choice Lists, filter by the child field, and you'll see all choices with their dependent values.
Section 3

String Field Validation — Regex

For String fields where only certain formats are valid (phone numbers, IP addresses, postal codes, product codes), you can add a regular expression validation directly in the field's dictionary entry. If a user enters a value that doesn't match the regex, the save is blocked with a validation error.

To add regex validation: open the field's dictionary entry, scroll to the Attributes field or the dedicated Validation section, and enter the regex pattern. For example, to validate a US phone number: ^\+?1?\s*\(?[0-9]{3}\)?[-.\s]?[0-9]{3}[-.\s]?[0-9]{4}$

💡
Tip — Test Regex Before Deploying Regex validation errors can block entire import pipelines if your source data doesn't perfectly match the pattern. Before adding regex validation to a production field, check existing data to ensure all current values pass the regex. Use a Script Include or Scheduled Script to run a pre-check before activating the validation.
Section 4

Managing Choice Lists

Choice lists are managed via two paths:

  1. Right-click the field on a form → Configure → Choice List — opens the choice editor for that specific field
  2. System Definition → Choice Lists — shows all choices for all tables, filterable by table/field

When you add a new choice, you specify: the table, the field name (element), the label, the value, the sequence (display order), and optionally a dependent value. Active checkbox controls whether the choice appears in the dropdown (inactive choices still exist but are hidden from the UI).

⚠
Exam Trap — Inactive Choices and Existing Data Making a choice "inactive" hides it from the dropdown for new entries, but it does NOT remove the value from records that already have it. Existing records with that inactive choice value still display the label correctly. The choice must remain in sys_choice even when inactive, or existing records will show a blank/unknown value for that field.
Section 5

Choice List vs. Lookup Table

For small, stable sets of options (5-15 values that rarely change), Choice Lists are the right tool. For larger, frequently-changing sets, or when each option needs additional metadata, a Lookup Table (standalone reference table) is better.

AspectChoice List (sys_choice)Lookup Table + Reference field
Who can add optionsDeveloper (requires dictionary access)Admin (add a row to the table)
Per-option metadataLabel + value onlyAny additional fields you define
Size limitPractical limit ~50 (performance/UX)Thousands of rows if needed
TranslationBuilt-in label translation per languageMust build translation mechanism yourself
Cross-table reuseOne definition per table+fieldOne table referenced by many fields
Exam Quick Reference

Common Exam Traps — Field Validation & Choice Lists

  • Choice fields store the value (e.g., 1), not the label (e.g., "New") — use values in conditions
  • Incident state values: 1=New, 2=In Progress, 3=On Hold, 6=Resolved, 7=Closed, 8=Cancelled
  • Dependent choice lists filter Sub-category options based on Category — configured via "Dependent value" on choice records
  • Regex validation on String fields blocks saves if value doesn't match — applies to forms AND APIs
  • Deactivating a choice hides it from dropdowns but existing records still display it correctly
  • Use Choice Lists for small stable sets; use Lookup Tables for large, changing, or metadata-rich option sets
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Field Validation & Choice Lists Quiz 1 / 4

A report filter uses "state = 'In Progress'" but returns no results, even though many incidents are in progress. What is the most likely cause?

💡 Explanation

B is correct. ServiceNow choice fields store numeric integer values in the database, not the display labels users see. For Incident state: 1=New, 2=In Progress, 3=On Hold, 6=Resolved, 7=Closed, 8=Cancelled. Filtering on the string "In Progress" finds nothing because the database contains "2". Scripts and conditions must always reference the stored value (integer), not the display label. Options A, C, and D describe unrelated issues — the root cause is the value-vs-label distinction.

An administrator deactivates the "Vendor Support" choice option from the Incident category field. What is the effect on existing records that already have "Vendor Support" as their category?

💡 Explanation

B is correct. Deactivating a choice only hides it from the dropdown — users can no longer select it for new/edited records, but all existing records retain their stored value and display the label correctly. The underlying value is still in sys_choice (just inactive) so ServiceNow can still resolve it to its label. Options A and D are wrong — deactivation never alters existing data. Option C is wrong — ServiceNow handles inactive choice values gracefully and continues to display them on existing records.

Which mechanism should be used when users must select a Sub-category value that dynamically narrows based on which Category was selected?

💡 Explanation

C is correct. Dependent Choice Lists are specifically designed for parent-child choice relationships where available child choices depend on the selected parent value. When Category = "Hardware", only hardware Sub-categories appear; when Category = "Software", software Sub-categories appear. Reference Qualifiers (A) are for reference fields pointing to another table, not choice fields. ACLs (B) control access/permissions, not choice filtering. Dictionary Overrides (D) change field attributes per-table, not per-choice-value.

A new field must accept only values matching the pattern "PRJ-NNNN" (e.g., PRJ-1234). Which validation mechanism enforces this format on the field?

💡 Explanation

B is correct. Regex validation on the field's dictionary entry enforces that input must match a specific pattern before the record saves. A pattern like ^PRJ-\d{4}$ requires exactly "PRJ-" followed by 4 digits. This applies to both form submissions AND API calls. Choice Lists (A) only work for predefined discrete values, not freeform pattern matching. The mandatory checkbox (C) only ensures a value exists, not that it matches a specific format. ACLs (D) control access permissions, not input format validation.

Score: 0 / 4
Next: Reference Qualifiers & Field Security →