GlideForm.getValue()

What It Does

The getValue() method retrieves the internal database value of a form field. This is fundamentally different from what users see on screen. For reference fields, it returns the sys_id of the referenced record, not the display value shown in the field. For choice fields, it returns the stored value (like 'new', 'in_progress') rather than the translated display label ('New', 'In Progress').

ServiceNow's form engine maintains both display and internal values for most field types. When you call getValue(), the platform bypasses any display formatting, translations, or decorations and returns the raw value that would be stored in the database. This happens entirely client-side using the form's cached field data—no server round-trip occurs.

The method returns null when the field doesn't exist on the form, and an empty string when the field exists but has no value. For boolean fields, it returns the string 'true' or 'false', not actual boolean values. Date/time fields return the internal ISO format, not the user's display format.

One critical edge case: if a reference field shows a display value but the underlying record has been deleted, getValue() still returns the original sys_id. The form doesn't validate reference integrity client-side. Multi-choice fields return a comma-separated string of internal values, not an array.

This method pairs with setValue() for field manipulation and contrasts with getDisplayValue() which returns formatted display values. Use getValue() when you need to compare field values, build queries, or perform logic based on actual data rather than user presentation.

When to Use This

Use getValue() when building conditional logic that depends on actual field values, not user display preferences. This includes comparing choice field values, checking reference field relationships, or constructing server-side queries from client-side data. It's essential when you need the value that will actually be saved to the database.

Avoid getValue() when displaying information to users—use getDisplayValue() instead. Don't use it for user-facing messages or alerts where readable text matters. A common mistake is using getValue() in error messages, showing users cryptic sys_ids or untranslated choice values instead of meaningful text.

The method is also the wrong choice when you need formatted data like currency with symbols, dates in user locale, or numbers with thousands separators. These scenarios require getDisplayValue() or specialized formatting methods. Remember: internal values are for logic, display values are for humans.

Return Value

Returns a string containing the field's internal value, or null if the field doesn't exist on the form. Even numeric and boolean fields return string representations. Empty fields return empty strings, not null. Date fields return ISO format strings (YYYY-MM-DD HH:mm:ss), regardless of user timezone or display preferences.

Always check for null before using the return value, especially in reusable code that might run on different forms. Use === '' to check for empty values, not == null, since empty fields return empty strings. For boolean comparisons, use === 'true' rather than truthy evaluation.

Platform Behavior & Side Effects

• No server-side business rules, ACLs, or workflow activities are triggered—this is purely client-side data retrieval
• Nothing is written to the database—the method only reads from the form's client-side field cache
• Extremely fast performance since it accesses cached form data without network requests
• Returns stale data if the underlying record was modified elsewhere—form data isn't automatically refreshed
• Works identically in UI Policies, Client Scripts, and UI Actions—no behavioral differences between contexts
• Does not respect field-level ACLs since it operates on already-loaded form data—security checks happened during form rendering
• Reference field values may point to deleted records—no referential integrity validation occurs client-side