GlideForm.addErrorMessage()

g_form.addErrorMessage(message)→ void

beginnerTested on Xanadu

What It Does

The addErrorMessage() method displays a red error message at the top of the current form, immediately below the form header. The message appears with a distinctive red background and error icon, making it clearly visible to users. ServiceNow's form rendering engine adds the message to a queue that displays all error messages in the order they were added.

Internally, ServiceNow maintains an array of error messages associated with the current form session. When you call addErrorMessage(), the platform pushes your message onto this array and immediately updates the DOM to render the error banner. The message persists until the user navigates away from the form, submits successfully, or the form is refreshed.

This method returns void and always succeeds - there are no failure conditions. Even if you pass null or undefined, ServiceNow will convert these to strings and display them. The message text is escaped to prevent XSS attacks, so HTML tags display as literal text rather than being rendered.

⚠️

addErrorMessage() does NOT prevent form submission. Users can still click Save or Update even with error messages displayed. Use return false in onChange scripts or mandatory field validation for actual submission prevention.

The method works alongside other GlideForm messaging methods like addInfoMessage() and clearMessages(). Multiple error messages stack vertically in the order added, and clearMessages() removes all messages including errors. Error messages have higher visual priority than info messages due to their red styling.

When to Use This

Use addErrorMessage() for client-side validation that requires user attention but allows them to continue working on the form. Perfect for onChange field validation, complex business rule violations, or when checking related record states that should block submission. Use it in Client Scripts when you need to inform users about data quality issues or missing required information across multiple fields.

For simple field-level validation, use showFieldMsg() instead to display the error directly next to the problematic field. For server-side validation that should absolutely prevent submission, implement your logic in Business Rules rather than relying on client-side messages. Use addInfoMessage() for warnings or informational content that doesn't indicate an error condition.

Avoid using this method for every validation scenario - too many error messages overwhelm users and reduce their effectiveness. Don't use it for validation that ServiceNow's mandatory field or data policy mechanisms can handle automatically. Never rely solely on client-side error messages for security or data integrity since users can disable JavaScript or manipulate the client.

Return Value

This method returns void (undefined) and provides no indication of success or failure. The operation always succeeds from a technical perspective - even invalid inputs get converted to strings and displayed. You cannot chain this method or use its return value in conditional statements.

Since the method provides no feedback about message display, you cannot programmatically determine if the user has seen or dismissed the error. The message remains visible until the user navigates away, the form refreshes, or clearMessages() is called. Design your validation logic accordingly, assuming the message will persist for the entire form session.

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 a client-side DOM manipulation with no Business Rules, Script Includes, or notifications triggered
Nothing gets written to the database - error messages exist only in the browser session and are not logged or stored
Extremely fast execution with no network round-trips required - the message displays immediately when called
Messages are not cached or persisted - refreshing the form or navigating away removes all error messages permanently
Works identically in Client Scripts, UI Policies, and UI Actions - no behavioral differences based on execution context
Multiple calls stack messages vertically without replacing previous ones - each call adds to the existing message queue
Message text is automatically escaped for XSS protection - HTML tags display as literal text and cannot be used for formatting

Parameters

Name	Type	Required	Description
message	string	Yes	The error message text to display to the user. HTML is not rendered - the message displays as plain text only. Empty strings will display as blank error messages.

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

function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading || newValue === '') {
        return;
    }
    
    // Check if priority is High but assignment group is empty
    if (newValue == '1' && g_form.getValue('assignment_group') === '') {
        g_form.addErrorMessage('High priority incidents must have an assignment group');
        // Note: this doesn't prevent saving, just warns the user
    }
    
    // Clear previous messages when validation passes
    if (newValue != '1' || g_form.getValue('assignment_group') !== '') {
        g_form.clearMessages();
    }
}

Shows basic usage in an onChange script for the priority field on incidents. The error appears immediately when the user selects high priority without an assignment group.

Multiple validation rules with stacked messagesintermediate

function onSubmit() {
    var hasErrors = false;
    
    // Clear any existing messages first
    g_form.clearMessages();
    
    // Validate business rules for incident closure
    if (g_form.getValue('state') == '6') { // Resolved
        if (g_form.getValue('close_code') === '') {
            g_form.addErrorMessage('Resolution code is required when resolving incidents');
            hasErrors = true;
        }
        
        if (g_form.getValue('close_notes') === '') {
            g_form.addErrorMessage('Resolution notes must explain how the issue was resolved');
            hasErrors = true;
        }
        
        if (g_form.getValue('u_customer_confirmed') != 'true') {
            g_form.addErrorMessage('Customer confirmation required before closing');
            hasErrors = true;
        }
    }
    
    // Allow submission even with errors - messages are just warnings
    return true;
}

Demonstrates stacking multiple error messages during form submission validation. Each validation adds its own message, creating a comprehensive error list for the user.

The classic mistake - expecting error messages to prevent submissionadvanced

// WRONG: This doesn't actually prevent saving
function onSubmit() {
    if (g_form.getValue('u_budget_amount') > 10000) {
        g_form.addErrorMessage('Budget amounts over $10,000 require approval');
        // User thinks this blocks submission but it doesn't!
    }
    return true; // Form still saves
}

// CORRECT: Combine with return false to actually block
function onSubmit() {
    if (g_form.getValue('u_budget_amount') > 10000 && 
        g_form.getValue('u_approval_received') != 'true') {
        g_form.addErrorMessage('Budget amounts over $10,000 require approval');
        return false; // This actually prevents submission
    }
    return true;
}

Shows the most common misunderstanding - error messages are informational only. You must explicitly return false from onSubmit to prevent form submission.

Gotchas

Error messages do not prevent form submission - users can still click Save/Update unless you return false from onSubmit or onChange scripts.

HTML tags in messages display as literal text rather than being rendered, so you cannot format messages with bold, links, or other HTML elements.

Messages persist until the user navigates away or clearMessages() is called - they don't automatically disappear when the underlying condition is fixed.

Multiple calls to addErrorMessage() stack the messages vertically rather than replacing the previous message, which can quickly overwhelm the form interface.

The method accepts any data type for the message parameter and converts it to a string, so passing objects or arrays results in cryptic [object Object] messages.

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