GlideForm.showFieldMsg() — ServiceNow API

g_form.showFieldMsg(fieldName, message, type)→ void

intermediateTested on Xanadu

What It Does

The showFieldMsg() method renders a message directly below a specific field on the current form. The message appears in the field's container area, visually connecting the feedback to the relevant input. ServiceNow injects a small div element immediately after the field's input wrapper with appropriate CSS classes for styling.

The platform maintains an internal registry of field messages per form session. When you call this method, ServiceNow updates this registry and immediately renders the visual change without requiring a form refresh. Multiple messages can exist simultaneously on different fields, but only one message per field - subsequent calls to the same field replace the previous message.

The method returns void and executes synchronously. If the specified field doesn't exist on the current form, the method fails silently - no error is thrown and no message appears. This differs from addInfoMessage() which always displays at the form header level.

Field messages persist through client-side form changes but disappear on form submission or page refresh. They don't trigger any server-side events or business rules since they're purely cosmetic UI elements. The messages are not accessible via screen readers by default, so consider this for accessibility requirements.

Related methods include clearMessages() which removes all field messages, and hideFieldMsg() which removes messages from specific fields. The global message methods addInfoMessage() and addErrorMessage() work at the form level rather than field level.

When to Use This

Use showFieldMsg() for field-specific validation feedback, format requirements, or contextual help that relates directly to a single field. Perfect for real-time validation in onChange client scripts, showing password requirements under password fields, or displaying calculation results next to computed fields. The proximity to the relevant field makes the user experience much clearer than header-level messages.

Don't use this for form-wide messages, submission confirmations, or anything requiring the user's immediate attention across the entire form. Use addErrorMessage() or addInfoMessage() instead. Avoid showing critical error messages that prevent form submission only at the field level - users might miss them. Also avoid this method for fields that aren't currently visible, as the message won't appear until the field becomes visible.

Common misuse includes trying to show multiple messages per field (only the last one displays), using it for debugging information that should go to the console, or expecting the messages to persist across form submissions. Remember that users scrolling quickly through long forms might miss field-level messages entirely.

Return Value

Returns void (undefined) in all cases. The method provides no feedback about whether the field exists, whether the message was successfully displayed, or whether the type parameter was valid. Success or failure must be determined by visual inspection of the form or by checking if the field exists beforehand using g_form.isVisible() or similar methods.

Since there's no return value to check, wrap calls in conditional logic if you need to verify field existence first. The method executes immediately and synchronously, so any visual changes appear right away if the field exists and is currently rendered on the form.

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 server-side events fire - this is purely client-side DOM manipulation with no database interaction
Messages are not logged, audited, or stored anywhere - they exist only in the current browser session
Performance impact is minimal - direct DOM manipulation without AJAX calls or server round-trips
Messages automatically clear when the form is submitted, refreshed, or navigated away from
Works identically in Client Scripts, UI Policies, and UI Actions - no behavioral differences between contexts
Messages persist through section expand/collapse and tab switching but disappear if the field is hidden via UI Policy
CSS classes applied are 'notification notification-info' for info type and 'notification notification-error' for error type

Parameters

Name	Type	Required	Description
fieldName	string	Yes	The field name where the message should appear. Must be a valid field on the current table. Message appears directly below the field input.
message	string	Yes	The text to display to the user. HTML is not rendered - treated as plain text. Empty strings will clear existing messages for that field.
type	string	Yes	Either 'info' (blue styling) or 'error' (red styling). Invalid types default to 'info'. Case-sensitive - 'Error' or 'INFO' won't work.

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 field validation with error messagebasic

// onChange client script for incident.short_description
function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading) return;
    
    // Clear any existing message first
    g_form.hideFieldMsg('short_description');
    
    if (newValue && newValue.length < 10) {
        g_form.showFieldMsg(
            'short_description',
            'Description must be at least 10 characters long',
            'error'
        );
        // Don't prevent saving, just warn the user
    }
}

Shows real-time validation feedback as users type. Notice we clear existing messages first to avoid stacking, and we're providing helpful guidance rather than blocking submission.

Dynamic help text based on field selectionintermediate

// onChange client script for incident.priority
function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading) return;
    
    var helpText = {
        '1': 'Critical - Business stopped. Escalation required within 15 minutes.',
        '2': 'High - Major business impact. Manager approval needed.',
        '3': 'Medium - Some business impact. Standard workflow applies.',
        '4': 'Low - Minor impact. Can be scheduled for later resolution.',
        '5': 'Planning - For future work. No immediate action required.'
    };
    
    g_form.hideFieldMsg('priority');
    
    if (newValue && helpText[newValue]) {
        g_form.showFieldMsg('priority', helpText[newValue], 'info');
    }
}

Provides contextual help that changes based on selection. Users get immediate feedback about what their choice means without cluttering the interface with static text.

The classic mistake - trying to show multiple messagesadvanced

// WRONG - Only the last message will show
function validateUser() {
    var userName = g_form.getValue('assigned_to');
    
    if (!userName) {
        g_form.showFieldMsg('assigned_to', 'User is required', 'error');
    }
    
    // This overwrites the previous message!
    g_form.showFieldMsg('assigned_to', 'Select from the list only', 'info');
}

// RIGHT - Combine messages or use different approaches
function validateUserCorrect() {
    var userName = g_form.getValue('assigned_to');
    
    if (!userName) {
        g_form.showFieldMsg(
            'assigned_to', 
            'User is required. Please select from the list.', 
            'error'
        );
    }
}

Only one message per field displays at a time. The second call completely replaces the first message, not appends to it. Combine related messages into a single coherent string instead.

Gotchas

Only one message per field displays at a time - subsequent calls to the same field completely replace the previous message, they don't stack or append.

Messages disappear immediately if the field is hidden by UI Policy or section collapse, even though the message technically still exists in memory.

Invalid field names fail silently with no error thrown - the method appears to work but nothing displays on screen.

The type parameter is case-sensitive - 'Error', 'INFO', or 'warning' won't work, only lowercase 'error' and 'info' are valid.

Field messages don't prevent form submission by themselves - they're purely informational and require separate validation logic to actually block saves.

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