GlideForm.getDisplayValue()

g_form.getDisplayValue(fieldName)→ string

beginnerTested on Xanadu

What It Does

The getDisplayValue() method retrieves the human-readable representation of a field's value, not the raw database value. This distinction becomes crucial when working with reference fields and choice lists, where the stored value differs significantly from what users see on screen.

Internally, ServiceNow performs a lookup operation when this method executes. For reference fields, it queries the referenced table to retrieve the display value of the referenced record. For choice fields, it accesses the choice list configuration to return the label corresponding to the stored choice value. The platform caches these lookups within the current session to improve performance.

The method returns a string containing the display value, or an empty string when the field is empty, doesn't exist, or the referenced record cannot be accessed due to ACL restrictions. Unlike getValue(), it never returns null - empty values consistently return empty strings.

Edge cases include mandatory reference fields without values (returns empty string), reference fields pointing to deleted records (returns empty string), and choice fields with custom values not in the choice list (returns the raw value). The method also handles dot-walked fields inconsistently - some dot-walked reference fields work while others return unexpected results.

This method pairs with getValue() and getReference() in the GlideForm arsenal. While getValue() returns sys_ids and choice values, and getReference() returns GlideElementReference objects, getDisplayValue() provides the user-friendly labels ideal for display purposes.

When to Use This

Use getDisplayValue() when building user-facing messages, populating read-only fields with human-readable content, or performing client-side validation that needs to reference what the user actually sees. It's essential for creating meaningful alert messages, confirmation dialogs, and field labels that make sense to end users rather than displaying cryptic sys_ids or choice values.

Avoid this method when you need the actual database value for queries, comparisons, or server-side operations. Use getValue() instead for programmatic operations, and use getReference() when you need to access additional fields from referenced records. Don't use getDisplayValue() for string fields, date fields, or numeric fields where the display value matches the stored value - it's unnecessary overhead.

Common misuse includes trying to set field values using display values (which fails), using display values in database queries server-side (they won't match), and assuming the display value will always match what you see in lists or forms (ACLs and personalization can alter display behavior).

Return Value

Returns a string containing the display representation of the field's value. For reference fields, this is the display value from the referenced record (typically the name field). For choice fields, this is the choice label as defined in the choice list. For other field types, the return value typically matches what getValue() would return, formatted according to the user's locale and preferences.

When the field is empty, the field doesn't exist, or access is denied, the method returns an empty string rather than null or undefined. This makes it safe to use in string concatenation and display operations without additional null checking, though you should still validate for meaningful content when the distinction between empty and missing matters.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

Platform Behavior & Side Effects

No Business Rules, notifications, or audit records are triggered by reading display values
ACLs are respected - if you can't read the referenced record, you get an empty string
Database queries may execute for reference field lookups, impacting performance on forms with many reference fields
Display values are cached within the current client session to avoid repeated lookups
Choice field translations are applied based on the user's current language preference
No database writes occur - this is a purely read operation that doesn't modify any records
Field security and encryption are bypassed for display purposes, but ACLs still apply to the underlying record access

Parameters

Name	Type	Required	Description
fieldName	string	Yes	The field name to retrieve the display value from. Must be a valid field on the current form's table. Returns empty string if field doesn't exist or has no value.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Code Examples

Basic usage — Reference and choice field display valuesbasic

// Get user-friendly values for incident form
function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading || newValue === '') return;
    
    // Reference field - shows user's full name instead of sys_id
    var assignedUserName = g_form.getDisplayValue('assigned_to');
    
    // Choice field - shows 'High' instead of '1'
    var priorityLabel = g_form.getDisplayValue('priority');
    
    // Build meaningful message for users
    if (assignedUserName && priorityLabel) {
        var message = 'Incident assigned to ' + assignedUserName + 
                     ' with priority: ' + priorityLabel;
        g_form.addInfoMessage(message);
    }
    
    // Compare with raw values to see the difference
    console.log('Display: ' + assignedUserName + ' vs Raw: ' + g_form.getValue('assigned_to'));
    console.log('Display: ' + priorityLabel + ' vs Raw: ' + g_form.getValue('priority'));
}

Shows the fundamental difference between display values and stored values. The display values create human-readable messages while raw values return sys_ids and choice keys.

Intermediate — Dynamic field validation with display valuesintermediate

// Validate configuration item assignment based on location
function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading || newValue === '') return;
    
    var callerLocation = g_form.getDisplayValue('caller_id.location');
    var ciLocation = g_form.getDisplayValue('cmdb_ci.location');
    
    // Only validate if both locations are available
    if (callerLocation && ciLocation) {
        if (callerLocation !== ciLocation) {
            var warningMsg = 'Warning: Caller location (' + callerLocation + 
                           ') differs from CI location (' + ciLocation + ')';
            g_form.addErrorMessage(warningMsg);
            
            // Optionally clear the CI field
            if (!confirm('Locations do not match. Keep this configuration item?')) {
                g_form.clearValue('cmdb_ci');
            }
        } else {
            g_form.hideFieldMsg('cmdb_ci', true);
        }
    }
}

Demonstrates dot-walking with display values for cross-reference validation. Uses display values to create meaningful error messages that help users understand location mismatches.

The Classic Mistake — Using display values for logicadvanced

// WRONG - Don't use display values for business logic
function badExample() {
    var priority = g_form.getDisplayValue('priority');
    
    // This breaks with different languages or custom choice labels
    if (priority === 'High') {
        // This logic fails in non-English instances
        g_form.setMandatory('assigned_to', true);
    }
}

// RIGHT - Use raw values for logic, display values for messages
function goodExample() {
    var priorityValue = g_form.getValue('priority');
    var priorityDisplay = g_form.getDisplayValue('priority');
    
    // Logic based on database value (language-independent)
    if (priorityValue === '1') {
        g_form.setMandatory('assigned_to', true);
        // User-friendly message with display value
        g_form.showFieldMsg('assigned_to', 'Assignment required for ' + priorityDisplay + ' priority', 'info');
    }
}

Shows why display values should never drive business logic. Display values change with language, customization, and user preferences, making logic unpredictable. Always use raw values for decisions.

Gotchas

Display values for reference fields return empty strings when the referenced record exists but you lack read access due to ACLs.

Choice field display values reflect the user's current language setting, so 'High' priority might display as 'Alto' for Spanish users.

Dot-walking with getDisplayValue() works inconsistently - some reference chains work while others return unexpected results or empty strings.

Custom choice values not defined in the choice list return the raw value instead of a meaningful label, breaking the expected behavior.

Empty reference fields return empty strings, not null, which can cause issues when checking for truly unset values versus legitimately empty fields.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue