GlideSystem.warn()

What It Does

The gs.warn() method writes messages to ServiceNow's system log at the WARN level. The platform processes these messages through the logging subsystem, where they're stored in the syslog table and made available through the System Logs module in the navigator.

When called, the method immediately writes the log entry with a timestamp, source information, and the formatted message. The logging system captures the current user context, transaction ID, and execution scope automatically. Messages support parameter substitution using numbered placeholders like {0}, {1}, which are replaced with corresponding parameter values.

The method returns void and cannot fail silently. If the logging subsystem is unavailable, the platform may skip the log entry but won't throw an exception. Parameter substitution handles null or undefined values by converting them to empty strings rather than the literal text 'null' or 'undefined'.

Edge cases include parameter mismatches where fewer parameters are provided than placeholders exist. In these scenarios, unreplaced placeholders remain as literal text in the final message. The method processes parameters in order, so {0} always maps to the first parameter value.

This method is part of the GlideSystem logging family alongside gs.info(), gs.error(), and gs.debug(). The WARN level sits between INFO and ERROR, making it visible in most production logging configurations while clearly indicating something needs attention.

When to Use This

Use gs.warn() for situations that represent potential problems but don't prevent normal operation. Classic scenarios include deprecated API usage, missing optional configuration, fallback logic activation, or data quality issues that the system can work around. These situations warrant investigation but shouldn't trigger immediate alerts like errors would.

Choose gs.error() when something actually breaks or fails validation. Use gs.info() for normal operational messages that confirm expected behavior. Avoid warning-level logging for routine operations or temporary conditions that resolve themselves without intervention.

Return Value

The method returns void (undefined in JavaScript terms). No return value is provided, and you cannot chain additional method calls or use the result in conditional logic. The method exists solely for its side effect of creating a log entry.

Since there's no success or failure indication, assume the log entry was created unless broader system issues prevent logging entirely. The platform handles logging failures internally without exposing them to your script execution.

Platform Behavior & Side Effects

• Creates a new record in the syslog table with level WARN, timestamp, and formatted message
• Captures current user, session ID, and transaction context automatically
• Does not trigger Business Rules, ACLs, or notifications on the syslog table
• Executes synchronously but with minimal performance impact (sub-millisecond typically)
• Log entries are subject to retention policies and may be archived or deleted based on system configuration
• Available immediately in System Logs module and Log Analysis tools
• Respects instance logging level configuration - may be filtered out if WARN level is disabled