Display Value

What It Is

Display Value is ServiceNow's mechanism for showing human-readable text in the user interface instead of the raw database values stored in fields. While IT systems generally distinguish between stored values and their presentation, ServiceNow's implementation is particularly sophisticated because it automatically resolves reference field relationships to show meaningful labels rather than sys_id values. When you see "John Smith" instead of "a1b2c3d4e5f6789012345678901234567" in a reference field, you're seeing the display value at work. This isn't just cosmetic formatting—it's a fundamental part of how ServiceNow maintains usability while operating on a complex relational data model underneath.

Architecturally, display values operate at the presentation layer but are deeply integrated with the data access layer through GlideRecord and the database abstraction layer. Every table in ServiceNow has a designated display value field—usually name or number—that determines what text represents that record when referenced elsewhere. This creates a cascade effect: when a cmdb_ci record is referenced in an incident, ServiceNow automatically fetches and displays the CI's name field value rather than its sys_id. This enables ServiceNow to maintain referential integrity at the database level while presenting meaningful information to users without requiring complex joins or lookups in every query.

From a business operations perspective, display values solve the fundamental problem of making enterprise data accessible to non-technical users who need to work with complex interconnected records. In ITSM practice, a single incident might reference a user, assignment group, configuration item, location, and business service—each stored as sys_id values in the database but displayed as "Jane Doe," "Network Operations," "PROD-WEB-01," "Chicago Data Center," and "Customer Portal" respectively. Without this abstraction, service desk agents would need to memorize or look up cryptic identifiers constantly, making the platform unusable for operational work. Display values enable ServiceNow to function as a business application rather than just a database interface.

ServiceNow designed display values this way because the platform needed to handle enterprise-scale data relationships while remaining usable by business users, not just database administrators. Alternative approaches like composite keys or manual lookups would have made the platform significantly more complex to use and maintain. The decision to automatically resolve display values through the GlideRecord API means developers get this functionality essentially for free—calling getDisplayValue() on any field returns human-readable text, while getValue() returns the stored database value. This design choice reflects ServiceNow's origins as a platform built for business users first, with technical functionality layered underneath rather than the reverse.

End users interact with display values constantly but unconsciously—they see them in forms, lists, and reference field typeaheads without thinking about the underlying complexity. Administrators configure which field serves as each table's display value and need to understand how changes affect the user experience across the platform. Developers work explicitly with display values through GlideRecord methods, often needing to choose between raw values for processing and display values for presentation or logging. Process owners care about display values because they determine what users see in workflows, notifications, and reports, directly affecting how business processes are understood and executed. Each group's interaction reflects a different layer of the same fundamental concept.

Without display values, ServiceNow would be essentially unusable as a business application. Users would see sys_id values everywhere, making it impossible to quickly identify records, understand relationships, or work efficiently with data. Reference fields would become lookup nightmares, reports would be meaningless to business users, and the platform would require constant cross-referencing between technical identifiers and business meaning. Notifications would contain gibberish, audit trails would be unreadable, and the entire concept of self-service would collapse because users couldn't navigate or understand the interface. Display values aren't just a convenience feature—they're what makes ServiceNow a platform rather than just a very expensive database with a web interface.

Where It Fits in the Platform

Display values sit at the intersection of ServiceNow's data model, user interface framework, and API layer. They're defined at the dictionary level for each table, automatically resolved by the GlideRecord engine, and rendered throughout the platform's presentation layer. This positioning makes them one of the most pervasive concepts in ServiceNow—touching everything from form rendering to workflow notifications to integration payloads. The platform's UI framework automatically invokes display value resolution whenever it needs to show reference field data, creating a seamless experience that hides the complexity of the underlying relational operations.

The concept bridges ServiceNow's technical architecture with its business application functionality. At the database level, display values are just another field designation in the dictionary, but at the application level, they enable the entire user experience. This dual nature means that changes to display value fields can have wide-reaching consequences across forms, reports, integrations, and business processes. Understanding display values is essential for anyone working with ServiceNow data, whether they're configuring user interfaces, writing scripts, designing integrations, or analyzing business processes.

Key Relationships:

• Dictionary: Each table's dictionary entry specifies which field serves as the display value, and changes to this setting affect how records from that table appear throughout the platform.
• GlideRecord: The getDisplayValue() and getValue() methods provide programmatic access to both the stored and display representations of field data.
• Reference Fields: Display values are what make reference fields usable by showing meaningful text instead of sys_id values in forms and lists.
• Choice Fields: Choice fields use their labels as display values while storing the underlying choice values, creating a similar stored-versus-displayed dynamic.
• Business Rules and Workflows: These often need to distinguish between using raw values for logic and display values for user-facing messages or notifications.
• Integrations: REST and SOAP APIs can return either stored values or display values depending on configuration, affecting how external systems interpret ServiceNow data.

How You Encounter This in Practice

Integration Data Confusion

You're a developer building an integration that exports incident data to a third-party system, and business users report that the exported data contains "useless codes" instead of readable information. The integration is pulling user assignments as values like "a1b2c3d4" instead of "John Smith," and urgency shows as "2" instead of "Medium." When you examine the code, you find it's using getValue() for all fields, which returns the stored database values rather than what users see in ServiceNow.

Understanding display values reveals that you need getDisplayValue() for fields where human readability matters, but getValue() for fields the receiving system needs to process programmatically. Without this knowledge, developers often create integrations that are either unusable by business users or impossible for external systems to process correctly, leading to failed implementations and rework.

Notification Template Debugging

You're an administrator troubleshooting email notifications that show "Assignment group: 8a9b0c1d" instead of readable group names, making the notifications confusing for recipients. The notification template uses ${assignment_group} which pulls the raw sys_id value. Users complain that the notifications are "full of system garbage" and want to disable them entirely.

Understanding display values shows you that ${assignment_group.getDisplayValue()} or the shorthand ${assignment_group.name} will show the group name instead of the sys_id. Without this knowledge, administrators often spend time investigating database corruption or integration issues when the problem is simply using the wrong field reference syntax in templates.

Catalog Variable Reporting Issues

You're a process owner creating reports on laptop requests from the service catalog, and the report shows user locations as cryptic codes like "LOC001" instead of "New York Office." The catalog item uses a reference variable pointing to the location table, but your report displays the location's u_code field instead of the name field. Business stakeholders reject the report as "unreadable" and question the value of the ServiceNow investment.

Understanding display values reveals that the location table's display value field is set to u_code instead of name, affecting how location references appear throughout the platform. You can either change the table's display value field or modify your report to explicitly reference location.name. Without this understanding, process owners often blame "bad data" when the issue is display value configuration, leading to unnecessary data cleanup projects and user frustration.

What People Get Wrong

This misconception leads to serious problems in business rules, workflows, and integrations where developers use getDisplayValue() when they should use getValue() for logic comparisons. Display values are the actual data that users see and interact with—they're not just a presentation layer. When you compare a choice field's value in a script condition, using current.state == 'In Progress' might fail because the stored value is "2" while the display value is "In Progress." Understanding when to use each method is critical for reliable automation.

The misconception exists because many developers come from environments where display formatting is purely cosmetic, separate from data processing. In ServiceNow, display values are integral to how the platform handles relationships and presents data to users. Business rules that incorrectly use display values for comparisons create intermittent failures that are difficult to troubleshoot, especially when they work in some environments but not others due to different language settings or customizations affecting display value resolution.

In production, this misunderstanding causes business rules to fail silently when comparing display values to stored values, integrations to send inconsistent data depending on which method is used, and workflows to take wrong paths when conditions evaluate incorrectly. The worst cases involve security rules or approval processes that bypass intended controls because the comparison logic uses the wrong value type. These failures are particularly dangerous because they often appear to work in testing but fail under specific data conditions or user contexts.

Changing which field serves as a table's display value has cascading effects throughout the platform that go far beyond UI appearance. Every reference to records from that table will show different text, affecting forms, lists, reports, notifications, and integrations. If you change the incident table's display value from number to short_description, every reference field pointing to incidents will suddenly show descriptions instead of incident numbers. This breaks user workflows, makes audit trails confusing, and can cause integration failures if external systems expect incident numbers but receive descriptions instead.

The misconception arises because administrators often think of display values as similar to field labels or UI formatting options that can be changed without affecting functionality. In reality, display values are part of the data model and changing them is more like renaming a primary key field than changing a cosmetic setting. The change affects every place where records from that table are referenced, including places administrators might not think to check like embedded reports, dashboard filters, or custom applications built on the platform.

In production, changing display values without proper planning causes user confusion as familiar identifiers disappear from the interface, breaks business processes that depend on specific text appearing in notifications or workflows, and creates integration issues when external systems receive unexpected data formats. Critical business processes like change approvals or incident escalations can fail when approval workflows or assignment rules can no longer identify the records they're supposed to process. The impact multiplies in large implementations where thousands of users and dozens of integrations depend on consistent record identification.

Admin vs Developer Perspective

For Admins

Admins control what users see through the Display value field configuration on each table, which determines how records appear in reference fields, related lists, and activity streams across the entire platform. When users complain they can't identify records in dropdowns or that "everything looks the same," it's usually because the display value field isn't configured with enough distinguishing information. The choice of display value field affects performance since ServiceNow indexes this field heavily, and changing it on heavily-used tables like sys_user or cmdb_ci requires careful planning and communication since it impacts every form, list, and report where those records appear. Admins need to balance human readability with uniqueness—a display value that's too generic creates confusion, while one that's too technical makes the interface unusable for business users.

For Developers

Developers must understand the critical difference between getValue() and getDisplayValue() when scripting, as mixing them up causes logic errors that are difficult to debug—you can't query for display values or use them in database operations. In server-side scripts, getDisplayValue() triggers additional database queries to resolve reference field display values, which can create performance problems in loops or bulk operations. When building integrations or APIs, always export the actual field values using getValue() since display values are intended for human consumption and can change without notice when admins modify table configurations. Custom display value logic in Business Rules or Client Scripts should account for null values and handle cases where the display value field itself contains references to other tables.

How It Connects to Other Concepts

• Reference Fields — the primary mechanism where display values matter most, as reference fields show the display value of the referenced record rather than the raw sys_id. When users select a record from a reference field dropdown, they see display values, but the actual field stores only the sys_id of the selected record. The performance of reference field lookups depends heavily on whether the display value field is properly indexed on the referenced table.
• GlideRecord — provides both getValue() and getDisplayValue() methods to access the stored value versus the human-readable version of any field. For reference fields, getDisplayValue() performs an additional query to fetch the display value from the referenced record, while getValue() returns only the sys_id.
• List Views — automatically show display values for reference fields in list columns, and users can click these display values to navigate to the referenced record. The list rendering engine optimizes these queries by batching display value lookups, but adding too many reference field columns to a list view can still impact performance. List personalization and filtering work against display values for reference fields, not the underlying sys_id values.
• Table Hierarchy — extended tables inherit the display value field from their parent table by default, but can override it to show more specific information relevant to the extended table's use case. When querying parent tables like task, the display values shown come from each record's actual table (incident, change_request, etc.), not necessarily the parent table's display value field configuration.
• Search — global search and reference field typeahead searches include display values in their search scope, making the choice of display value field critical for findability. If users can't locate records through search because the display value doesn't contain the terms they're looking for, they'll struggle to use reference fields effectively. Search weight and ranking algorithms give higher priority to matches in display value fields compared to other fields on the table.
• Activity Stream — uses display values when showing related record changes and updates, making audit trails and history more readable for end users. When reference fields change, the activity stream shows both the old and new display values rather than sys_ids, but this depends on the system capturing display values at the time of change rather than looking them up dynamically.

Junior vs Senior Knowledge Gap

Junior developers consistently confuse when to use getValue() versus getDisplayValue(), often grabbing display values for database operations or comparisons, which breaks when admins change display value field configurations. They write scripts that work in development but fail in production because they're comparing "John Smith" to "Smith, John" when the display format changes between environments. Junior admins frequently choose display value fields that seem logical in isolation—like short_description on incident—without considering that display values need to be unique enough to distinguish records when they appear in dropdowns with hundreds of similar items. They don't realize that changing a display value field after go-live affects every saved filter, report, and personalized list that references that table.

The mental shift happens when you realize display values are a presentation layer concept, not a data integrity concept—they can change without affecting the underlying data relationships, but they dramatically impact user experience and system performance. Senior professionals understand that display value strategy is as important as data model design because it affects every user interaction with the platform. They've learned that the "perfect" display value balances uniqueness, readability, and performance—usually some combination of identifier and descriptive text rather than just one or the other. Experience teaches you that display values for critical tables like users, CIs, and locations need to work across multiple contexts: form dropdowns, list views, reports, and mobile interfaces all have different space constraints and usage patterns.

Senior architects know that display value fields should never reference other tables unless absolutely necessary, because it creates a chain of lookups that kills performance and makes the system fragile to changes in referenced tables. They've seen production systems brought to their knees by poorly chosen display values that require complex joins or calculations to resolve. They understand the indexing implications—ServiceNow automatically indexes display value fields, but if your display value is a calculated field or references other tables, those indexes become less effective. The hard-won knowledge is that display value changes are among the most disruptive "simple" changes you can make in ServiceNow because they ripple through every part of the user experience.

Experienced professionals ask questions that juniors never consider: How will this display value perform when the table has 100,000 records? What happens when users search for records using terms that don't appear in the display value? How will this look on mobile devices where screen space is limited? Will business users understand these display values without training? They've learned to test display value changes across different form factors and user roles before implementation, and they always have a rollback plan because changing display values affects too many parts of the system to change casually. They know which tables are too risky to modify display values on (like sys_user or sys_user_group) and which ones desperately need better display values to improve usability.

Quick Reference

• The sys_user table's display value defaults to name but most organizations change it to include employee number or email to handle duplicate names—changing this affects every assignment field across the entire platform.
• Display values are limited to 40 characters in most dropdowns and reference field displays, so longer values get truncated with ellipses, making uniqueness even more critical in the first 40 characters.
• Calling getDisplayValue() on a reference field in a loop can generate hundreds of additional database queries—use addQuery().addOrCondition() or join queries instead for bulk operations.
• The incident table inherits its display value from task.number, which is why incidents show as "INC0000123" in reference fields rather than their short description.
• ServiceNow automatically creates database indexes on display value fields, but these indexes become less effective if the display value field contains long text or calculated values.
• Reference field typeahead search looks for matches in both the display value and the sys_id, so users can find records by typing part of the sys_id even when it's not the display value.
• The cmdb_ci table uses name as its display value, but CI names often aren't unique across different CI classes, causing confusion in CMDB relationship fields.
• Display values in email notifications and workflow activities are resolved at the time the email is sent or activity executes, not when the workflow starts, so they reflect the current state of referenced records.
• Import sets and data imports work with display values for reference fields by default, but you can override this behavior by mapping to the actual reference field name with .sys_id appended to skip display value resolution.
• Some tables like sys_choice and sys_user_role have their display value field set to technical names rather than human-readable labels, requiring custom reference qualifiers or display business rules for better usability.