Message

What It Is

A Message in ServiceNow is a translatable text string stored in the sys_ui_message table that enables consistent, multilingual text management across the platform. Unlike generic IT messaging systems that handle data transmission, ServiceNow Messages are static text resources designed to support internationalization (i18n) and centralized content management. Each Message record contains a key-value pair where the key serves as a unique identifier and the value contains the actual text content, with additional fields supporting language variants and contextual metadata.

Architecturally, Messages sit in the presentation and localization layer of the ServiceNow platform, bridging the gap between application logic and user interface text. They operate independently of the core data model but integrate deeply with the platform's rendering engine, allowing developers to separate hardcoded text from business logic while maintaining dynamic content capabilities. The system supports parameterization through placeholder substitution, enabling Messages to incorporate dynamic values while preserving the base text structure for translation purposes.

From a business operations perspective, Messages solve the fundamental problem of managing user-facing text across global ServiceNow implementations. Organizations operating in multiple countries need consistent terminology, error messages, and interface text that adapts to local languages and cultural contexts without requiring separate application instances. Messages enable IT teams to maintain a single codebase while supporting dozens of languages, reducing maintenance overhead and ensuring consistency in user experience across geographic regions.

ServiceNow designed the Message system this way because traditional approaches to internationalization—like maintaining separate code files or database tables for each language—create exponential complexity in enterprise software. The centralized sys_ui_message approach allows translators to work independently of developers, enables bulk translation imports and exports, and provides audit trails for text changes. Alternative approaches like inline translation functions or external localization services exist, but they lack the tight integration with ServiceNow's upgrade processes and domain separation capabilities that Messages provide.

The interaction model varies significantly across roles: developers reference Messages through gs.getMessage() and getMessage() calls in their scripts, treating them as dynamic text resources. Administrators manage Message records directly through the sys_ui_message table, often importing translations in bulk or coordinating with localization teams. End users never directly interact with Messages but experience their output through translated interfaces, error messages, and notifications. Process owners care about Messages primarily during global rollouts where consistent terminology becomes critical for user adoption and training standardization.

Without Messages, ServiceNow implementations would require hardcoded text strings scattered throughout scripts, UI policies, and business rules, making internationalization virtually impossible at enterprise scale. Every text change would require code modifications, every new language would require duplicate development effort, and maintaining consistency across applications would become a manual coordination nightmare. The absence of Messages would force organizations to choose between monolingual deployments or maintaining separate instances for each region—both approaches that undermine the platform's goal of unified service management across global enterprises.

Where It Fits in the Platform

Messages occupy a unique position in ServiceNow's architecture as content resources that span multiple platform layers while remaining data-agnostic. They integrate with the platform's rendering engine at the presentation layer, connect to the scripting framework through server-side and client-side APIs, and participate in the upgrade and update set processes as configuration data. This positioning allows Messages to influence user experience without being coupled to specific applications or business logic, making them reusable across different ServiceNow modules and custom applications.

The Message system intersects with ServiceNow's metadata management approach, where configuration elements like UI pages, business rules, and notifications reference Messages by key rather than storing text directly. This creates a dependency hierarchy where Messages serve as foundational content that higher-level platform components consume, similar to how system properties provide configuration values or how choice lists provide standardized option sets. The system's integration with domain separation and scoped applications further positions Messages as shared resources that can be isolated or inherited based on organizational boundaries.

Key Relationships:

• GlideSystem: The gs.getMessage() method provides server-side access to Message content, handling language detection and parameter substitution automatically.
• GlideForm: Client-side scripts use getMessage() to retrieve translated text for dynamic UI updates, validation messages, and user prompts.
• Domain Separation: Messages respect domain boundaries, allowing different organizational units to maintain separate text content while sharing common messages through inheritance.
• Upgrade: Messages participate in the platform's upgrade process, with out-of-box Messages being updated automatically while preserving custom Message modifications through conflict resolution.
• Business Rules: Server-side automation frequently uses Messages to generate consistent notification text, error messages, and audit comments that adapt to user language preferences.
• Dictionary: Field labels, help text, and choice options can reference Messages to support translated form interfaces while maintaining data integrity in the underlying tables.

How You Encounter This in Practice

Building Custom Applications for Global Deployment

You're a ServiceNow developer building a custom incident management enhancement that needs to deploy across your organization's offices in twelve countries. During development, you initially hardcode error messages and validation text directly in your client scripts and business rules, focusing on functionality over internationalization. When the pilot deployment reaches your German office, users report that English-only error messages create confusion during critical incident resolution, and the localization team requests all user-facing text be externalized for translation.

Understanding Messages unlocks the ability to refactor your hardcoded text into translatable resources that maintain code functionality while enabling localization. You extract validation messages like "Priority cannot be changed after assignment" into Message records with keys like priority_change_validation_error, then replace your hardcoded strings with gs.getMessage() calls that dynamically retrieve appropriate language versions.

Without understanding Messages, developers typically attempt internationalization through conditional logic that checks user language preferences and maintains separate text variables for each language—an approach that becomes unmaintainable with multiple languages and creates code bloat. They might also try to store translations in custom tables or configuration records, missing the platform's built-in language detection, parameter substitution, and upgrade protection capabilities that Messages provide.

Troubleshooting Missing or Incorrect Text Display

You're a ServiceNow administrator investigating user reports that certain interface elements show message keys like incident.priority.high instead of readable text like "High Priority." The issue appeared after a recent update set deployment from development, and only affects specific users in your Madrid office who have Spanish language preferences. Your initial investigation focuses on UI policies and form configurations, but the technical keys appearing suggest a deeper platform issue rather than simple display logic problems.

Understanding Messages reveals that this symptom indicates missing or improperly deployed Message records in the sys_ui_message table. When gs.getMessage() cannot find a Message record matching the requested key and language, it returns the key itself as a fallback. You can quickly diagnose the issue by checking if Spanish-language Message records exist for the problematic keys and whether the update set included all necessary Message translations.

Without understanding Messages, administrators often waste time investigating UI policies, dictionary entries, and client scripts, missing the fundamental issue that text content is managed separately from display logic. They might attempt to fix the problem by modifying form layouts or field properties, or assume the issue requires code changes rather than simply deploying missing Message records or importing translation files.

Managing Text Consistency During Platform Upgrades

You're a ServiceNow architect preparing for a major platform upgrade from Quebec to Rome, and your organization has extensively customized user-facing text throughout the platform to match internal terminology and branding standards. During upgrade preparation, you discover that many of your text modifications were made by directly editing out-of-box Message records rather than creating custom ones, creating potential conflicts when the upgrade process attempts to update those same Messages with new ServiceNow content. The preview upgrade instance shows numerous text inconsistencies where your customizations were overwritten.

Understanding Messages reveals that the platform treats Message records as upgradeable configuration data, with specific rules governing how custom modifications are preserved or overwritten during platform updates. You can identify which Messages will conflict by examining their sys_package and update tracking fields, then proactively create custom Message records with different keys to preserve your terminology while allowing out-of-box Messages to update cleanly.

Without understanding Messages, administrators often approach upgrade text conflicts reactively, manually comparing and merging text differences after the upgrade completes. This approach risks losing important customizations, introduces inconsistencies in user experience, and requires extensive post-upgrade validation. They might also attempt to preserve customizations by skipping Message updates entirely, missing important platform improvements and potentially breaking functionality that depends on updated Message content.

What People Get Wrong

This misconception severely underestimates Messages' role in platform operations and leads to dangerous assumptions about their replaceability and importance. Messages are dynamic platform resources that participate in upgrade processes, domain separation, and scoped application packaging—they carry metadata about versioning, ownership, and dependencies that directly affects platform stability. When administrators treat them as simple text strings, they often modify out-of-box Messages directly instead of creating custom ones, leading to upgrade conflicts that can break functionality or cause data loss.

The misconception arises because Messages appear as simple key-value pairs in the sys_ui_message table, hiding their integration with platform systems like the translation framework, parameter substitution engine, and configuration management processes. Many Messages actually control platform behavior—error messages that determine how validation failures are presented to users, confirmation prompts that affect workflow progression, and status indicators that influence user decision-making. Modifying these Messages without understanding their functional context can alter user behavior in ways that break business processes.

In production, this misunderstanding manifests when administrators bulk-modify Messages to fix terminology issues without considering upgrade implications, only to discover during the next platform update that critical system Messages have been reset to default values, breaking custom workflows that depended on specific text content. More subtly, treating Messages as static content leads to poor internationalization practices where organizations maintain separate ServiceNow instances for different regions instead of leveraging the platform's built-in translation capabilities, multiplying maintenance overhead and creating data integration challenges.

The most serious consequences occur when this misconception combines with aggressive customization practices—administrators who view Messages as "just text" often modify hundreds of out-of-box Message records to align with organizational preferences, creating massive upgrade conflicts that require manual resolution. During major platform updates, these conflicts can force organizations to choose between losing months of terminology customization or deferring critical security and functionality updates, creating operational risk that extends far beyond simple text display issues.

This approach directly contradicts ServiceNow's configuration management principles and creates serious upgrade risks that many organizations don't discover until they attempt major platform updates. Out-of-box Messages are owned by ServiceNow and updated during platform upgrades to reflect new functionality, bug fixes, and security improvements. When you modify these Messages directly, you create update conflicts that can block upgrades, force manual merge processes, or worse, cause your customizations to be silently overwritten without warning during automated update processes.

The misconception stems from database normalization principles that typically discourage data duplication, leading administrators to believe that creating custom Messages with similar content violates best practices. However, ServiceNow's configuration management model treats out-of-box and custom configurations as separate layers that must remain isolated to preserve upgradeability. The platform provides specific mechanisms for extending or overriding out-of-box content through custom records, and Messages follow this pattern—custom Message keys should reference custom functionality while out-of-box Message keys should remain untouched to maintain platform integrity.

The production consequences are severe and often delayed, making them particularly dangerous for organizations that don't regularly test upgrade processes. During platform upgrades, modified out-of-box Messages create conflicts that require manual review and decision-making for each affected record. In large implementations with hundreds of Message customizations, this process can extend upgrade windows by days or weeks, forcing organizations to maintain outdated platform versions with known security vulnerabilities. Even worse, some upgrade processes automatically resolve conflicts by reverting to out-of-box versions, silently breaking custom functionality that depends on the modified Message content without generating obvious error symptoms.

Admin vs Developer Perspective

For Admins

Admins primarily manage messages through the sys_ui_message table to customize user-facing text across the platform without requiring code changes. They need to understand that deleting or modifying system messages can break out-of-box functionality, particularly around UI policies, catalog items, and workflow notifications. The key decision admins make is whether to modify existing messages or create new ones — modifying system messages affects upgrade paths and can cause confusion during instance updates. Understanding the language field is crucial for maintaining proper internationalization support even in single-language environments.

For Developers

Developers leverage the gs.getMessage() server-side API and getMessage() client-side API to dynamically retrieve translatable strings, supporting parameter substitution for dynamic content. The pattern involves creating message keys that follow consistent naming conventions and avoiding hardcoded strings in scripts, particularly for error messages and user notifications. Developers must understand that message resolution happens at runtime based on the user's language preference, making it essential to test multilingual scenarios even in development instances. Building custom applications requires creating message records programmatically through GlideRecord operations against sys_ui_message, especially when deploying scoped applications that need their own message namespace.

How It Connects to Other Concepts

• User Preferences — the user_preferences table stores each user's language setting, which directly controls which message variant gets returned by gs.getMessage(). When a user changes their language preference, all subsequent message API calls automatically return content in that language without requiring code changes.
• Scoped Applications — each scoped app maintains its own message namespace through the sys_scope field on message records, preventing conflicts between applications that use similar message keys. Messages created within a scoped application are automatically scoped and can only be accessed by that application's scripts unless explicitly made global.
• Client Scripts — the client-side getMessage() function requires an AJAX call to the server to resolve message content, making it asynchronous and requiring callback patterns or promises. This relationship means that client-side message usage has performance implications that server-side usage doesn't have.
• Email Notifications — notification templates can reference message keys using the ${gs.getMessage()} syntax, allowing email content to be automatically translated based on the recipient's language preference. This integration ensures that notification content remains consistent with the rest of the user interface across different languages.
• Business Rules — server-side business rules commonly use messages for error handling and user feedback through gs.addErrorMessage() and gs.addInfoMessage() combined with gs.getMessage(). This pattern ensures that validation messages and system feedback remain translatable and consistent across different parts of the application.
• Update Sets — message records are automatically captured in update sets when modified, but the language field creates complications during deployment since each language variant exists as a separate record. Moving messages between instances requires careful attention to language-specific records and can create conflicts if target instances have different language configurations.

Junior vs Senior Knowledge Gap

Junior developers typically treat messages as simple string storage and miss the critical relationship between message keys and language resolution. They'll hardcode strings in scripts or create message records without considering the language field implications, often leaving it blank and wondering why messages don't work correctly in multilingual environments. The most common mistake is modifying out-of-box message content directly instead of creating language-specific variants, which breaks during upgrades. Junior developers also struggle with parameter substitution in messages, either avoiding it entirely or implementing string concatenation instead of using the proper {0}, {1} placeholder syntax.

The shift to senior-level understanding happens when developers realize that messages are part of the application's data model, not just configuration. They start thinking about message key naming conventions that scale across large implementations and understand that empty language fields create default fallback behavior that works differently than language-specific records. Senior developers architect message hierarchies that support both current requirements and future internationalization needs, even in organizations that claim they'll never need multiple languages. They also understand the performance implications of client-side message resolution and plan accordingly.

Experienced architects know that message resolution follows a specific fallback hierarchy that's never clearly documented — the platform checks user language first, then falls back to system default, then to any message with a blank language field, and finally returns the key itself if no message is found. They understand that the application field on message records affects scoping in ways that aren't obvious, and that clone operations between instances don't always preserve language-specific message variants correctly. Senior professionals also know that certain special characters in message keys can cause resolution failures, particularly periods and spaces, even though the platform doesn't prevent you from using them.

The questions that separate seniors from juniors center around upgrade safety and long-term maintenance: How will custom messages behave during platform upgrades? What happens when users switch languages mid-session? How do you bulk-create message variants for new languages without breaking existing functionality? Experienced architects also ask about performance implications — they know that excessive client-side message calls can impact form load times and plan message usage patterns accordingly. They understand that message keys themselves become part of the API contract for scoped applications and require versioning considerations.

Quick Reference

• Message keys with periods (like com.company.error.message) can cause resolution failures in certain contexts, despite being valid in the key field
• The language field uses ISO language codes but ServiceNow's resolution logic treats empty values as universal fallbacks, not English-specific
• Client-side getMessage() calls are asynchronous and can create race conditions if not handled with proper callbacks or promises
• Parameter substitution supports up to 10 parameters ({0} through {9}) and parameters are passed as additional arguments to the getMessage functions
• Scoped application messages are automatically prefixed with the application scope in the sys_scope field and cannot be accessed by other scoped applications
• Update set conflicts for messages are common during deployment because each language variant creates a separate record with different sys_id values
• The platform returns the message key itself as a string if no matching message record is found, making missing messages obvious in the UI
• Message records with the application field set to 'Global' are accessible from any scope, including scoped applications
• HTML content in the message field is automatically escaped when displayed in most UI contexts, requiring specific handling for rich content
• Language switching by users takes effect immediately for new page loads but doesn't affect already-loaded client-side cached message content