GlideSystem.addErrorMessage()

gs.addErrorMessage(message)→ void

beginnerTested on Xanadu

What It Does

The addErrorMessage() method queues an error message to display as a red banner at the top of the user's browser window. The message appears after the current server-side script completes and the response reaches the client. ServiceNow stores these messages in the user's session and displays them on the next page load or form refresh.

Internally, ServiceNow adds the message to a session-based queue that gets processed by the client-side framework. The platform automatically HTML-encodes the message content and strips out potentially dangerous tags to prevent cross-site scripting attacks. Multiple calls to addErrorMessage() within the same transaction will stack multiple error banners on the user's screen.

The method returns void and never fails or throws exceptions, even if passed null or undefined values. When given non-string parameters, ServiceNow converts them using JavaScript's standard string coercion rules. Empty strings display as blank error banners, which can confuse users.

⚠️

addErrorMessage() does NOT prevent saves, updates, or other operations. The transaction continues normally unless you also call setAbortAction(true).

This method works closely with gs.addInfoMessage() and gs.addMessage() to provide different message severity levels. Unlike client-side g_form.addErrorMessage(), the server-side version cannot target specific form fields and always appears at the page level.

When to Use This

Use addErrorMessage() when you need to notify users about validation failures, business rule violations, or critical errors that occurred during server-side processing. This is particularly useful in before Business Rules where you want to explain why a record cannot be saved, or in Script Includes called by AJAX requests where you need to communicate errors back to the user interface.

For field-specific validation errors, use current.fieldName.setError() instead, which highlights the problematic field and positions the error message near the input. For informational messages that aren't errors, use gs.addInfoMessage() which displays blue banners instead of red ones.

Avoid using this method for debugging or logging purposes — error messages appear to end users and can cause confusion. Never use it to display sensitive information like passwords, API keys, or internal system details that users shouldn't see.

Return Value

This method returns void (undefined in JavaScript). It provides no feedback about whether the message was successfully queued or will be displayed. The method always succeeds from a technical perspective, even when given invalid input parameters.

Since there's no return value to check, you cannot determine if the user will actually see the message. Messages may not appear if the user navigates away immediately, if their session expires, or if client-side errors prevent the page from rendering properly.

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, ACLs, or notifications are triggered by this method — it only affects the user interface
Messages are stored temporarily in the user's server-side session and cleared after being displayed once
Performance impact is minimal — the method executes in microseconds and doesn't query the database
Works identically in before/after Business Rules, Script Includes, and Scheduled Jobs, but messages from background jobs are never seen by users
Messages persist across redirects within the same session but are lost if the user opens a new tab or browser window
Multiple error messages stack vertically on the page, with the most recent message appearing at the bottom of the stack
Error messages are automatically logged to the system log with INFO severity, not ERROR, which can complicate troubleshooting

Parameters

Name	Type	Required	Description
message	string	Yes	The error message text to display in the red banner. HTML tags are stripped for security. ServiceNow automatically escapes special characters to prevent XSS attacks.

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 validation error in before Business Rulebasic

// Before Business Rule on incident table
if (current.priority.nil() && current.impact <= 2) {
    // High impact with no priority set
    gs.addErrorMessage('High impact incidents must have a priority assigned');
    
    // Prevent the save from completing
    gs.setAbortAction(true);
}

// Multiple validation errors stack
if (current.assigned_to.nil() && current.state == 2) {
    gs.addErrorMessage('In Progress incidents must be assigned to someone');
    gs.setAbortAction(true);
}

// Without setAbortAction, the record saves despite error messages
if (current.short_description.toString().length < 10) {
    gs.addErrorMessage('Description seems too short - consider adding more detail');
    // This saves anyway, message is just a warning
}

Shows the critical pattern of combining error messages with setAbortAction() to actually prevent saves. Multiple messages stack on the user's screen.

Script Include returning user feedbackintermediate

var IncidentUtils = Class.create();
IncidentUtils.prototype = {
    
    assignToAvailableAgent: function(incidentSysId) {
        var inc = new GlideRecord('incident');
        if (!inc.get(incidentSysId)) {
            gs.addErrorMessage('Incident not found: ' + incidentSysId);
            return false;
        }
        
        // Find available agents in the assignment group
        var agent = new GlideRecord('sys_user');
        agent.addActiveQuery();
        agent.addQuery('u_available_for_assignment', true);
        agent.query();
        
        if (!agent.next()) {
            gs.addErrorMessage('No agents available in ' + inc.assignment_group.getDisplayValue());
            return false;
        }
        
        inc.assigned_to = agent.sys_id;
        inc.update();
        
        gs.addInfoMessage('Assigned incident ' + inc.number + ' to ' + agent.getDisplayValue());
        return true;
    }
};

Script Includes can use addErrorMessage() to communicate results back to UI Actions or client scripts that call them. Mix with addInfoMessage() for different severity levels.

The classic mistake — forgetting setAbortActionadvanced

// WRONG: This doesn't prevent anything
(function executeRule(current, previous) {
    if (current.u_budget > 50000 && !current.u_approval_received) {
        gs.addErrorMessage('Budget requests over $50K require approval');
        // Record still saves! User sees error but operation completes
    }
})(current, previous);

// RIGHT: Actually prevent the save
(function executeRule(current, previous) {
    if (current.u_budget > 50000 && !current.u_approval_received) {
        gs.addErrorMessage('Budget requests over $50K require approval');
        gs.setAbortAction(true); // Now it actually stops the save
    }
    
    // Better yet, use field-level validation for specific fields
    if (current.u_vendor.nil() && current.state == 'approved') {
        current.u_vendor.setError('Approved requests must specify a vendor');
        gs.setAbortAction(true);
        // This highlights the vendor field specifically
    }
})(current, previous);

The most common mistake is showing error messages but forgetting to actually prevent the operation. Also shows when field.setError() is more appropriate than page-level messages.

Gotchas

Error messages display to users but don't prevent saves, updates, or deletes unless you also call gs.setAbortAction(true)

Messages from Scheduled Jobs or other background processes are queued but never displayed since no user session exists

HTML tags in messages are stripped automatically, so you cannot format messages with bold, italic, or links

Empty string messages create blank red banners that confuse users — always check for meaningful content before calling this method

Messages persist across redirects but disappear if users refresh the page or open new browser tabs, making them unreliable for critical communications

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