GlideRecord.hasNext() — ServiceNow API

hasNext()→ boolean

intermediateTested on Xanadu

What It Does

The hasNext() method peeks ahead in your query results to determine if more records exist beyond the current cursor position. Unlike next(), it doesn't advance the cursor or make the next record available for processing. The cursor remains exactly where it was before the call.

Internally, ServiceNow maintains a result set cursor that tracks your position within the returned records. When you call hasNext(), the platform checks if the cursor position plus one contains a valid record. This operation doesn't trigger database queries if the results are already cached, but may cause additional database hits if the result set hasn't been fully loaded.

The method returns true if at least one more record exists after the current position, false if you're at the end of the result set. Before any calls to next(), the cursor position is before the first record, so hasNext() will return true if any records match your query.

Edge cases include scenarios where record permissions change between the hasNext() call and subsequent next() calls. If ACLs deny access to the next record after hasNext() returns true, the following next() call may skip that record and advance to the next accessible one.

Relationship to other GlideRecord methods: hasNext() complements next() for iteration control, but next() already returns false when no more records exist. The getRowCount() method provides the total number of records, while hasNext() only tells you about immediate next record availability.

When to Use This

Use hasNext() only when you need to perform different logic based on whether more records exist before processing them. This includes scenarios like building comma-separated lists where you need to know if you should add a delimiter, or when implementing custom pagination logic where you display different UI elements based on result availability. The method is also useful when you need to conditionally execute expensive operations only if more data exists.

For standard record iteration, use next() directly in your while loop condition instead of checking hasNext() first. The pattern while (gr.hasNext()) { gr.next(); } is redundant and slower than while (gr.next()) { }. When counting records, use getRowCount() instead of iterating with hasNext().

⚠️

The pattern while (gr.hasNext()) { gr.next(); } makes two method calls per iteration instead of one. This doubles your loop overhead for no benefit.

Return Value

Returns a boolean value: true if more records are available from the current cursor position, false if you've reached the end of the result set. The method never returns null or undefined - it always returns a proper boolean even when called on an uninitialized GlideRecord.

If you call hasNext() before executing query(), it returns false because no result set exists. You can safely use the return value in conditional statements without additional null checking.

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, ACL checks, or audit records are triggered by hasNext() calls - it only checks cursor position
No database writes occur - this is a read-only operation that doesn't modify data
Performance is fast when results are cached, but may trigger additional database queries if the result set isn't fully loaded
Behaves identically in Business Rules, Script Includes, and Scheduled Jobs - no context-specific differences
Result may change between calls if underlying data is modified by other transactions during iteration
Memory usage remains constant - the method doesn't load additional records into memory
Transaction isolation level affects whether you see records created/modified by concurrent transactions

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

Building comma-separated list with proper formattingbasic

// Build a list of incident numbers with proper comma placement
var gr = new GlideRecord('incident');
gr.addQuery('state', '2');
gr.addQuery('priority', '1');
gr.query();

var incidentList = '';
while (gr.next()) {
    incidentList += gr.number;
    
    // Only add comma if more records follow
    if (gr.hasNext()) {
        incidentList += ', ';
    }
}

gs.info('High priority open incidents: ' + incidentList);
// Output: "INC0000123, INC0000124, INC0000125"

This shows the classic use case for `hasNext()` - determining if you should add a delimiter. Without it, you'd get a trailing comma or need more complex string manipulation.

Conditional processing based on remaining recordsintermediate

// Process incidents differently based on batch size remaining
var gr = new GlideRecord('incident');
gr.addQuery('state', 'IN', '1,2,3');
gr.orderBy('sys_created_on');
gr.query();

var processedCount = 0;
while (gr.next() && processedCount < 50) {
    // Do expensive processing
    processIncident(gr);
    processedCount++;
    
    // Only send progress notification if more work remains
    if (gr.hasNext() && processedCount % 10 === 0) {
        gs.eventQueue('incident.batch.progress', gr, processedCount);
    }
}

function processIncident(incident) {
    // Simulate expensive operation
    incident.work_notes = 'Processed on ' + new GlideDateTime();
    incident.update();
}

Here `hasNext()` prevents unnecessary progress notifications when you're processing the final batch. This avoids sending events when no more work remains.

The classic mistake - redundant hasNext checkingadvanced

// WRONG - Double method calls per iteration
var gr = new GlideRecord('incident');
gr.query();

while (gr.hasNext()) {
    gr.next();  // This is redundant!
    gs.info('Processing: ' + gr.number);
}

// RIGHT - Single method call per iteration
var gr2 = new GlideRecord('incident');
gr2.query();

while (gr2.next()) {
    gs.info('Processing: ' + gr2.number);
}

// The next() method already returns false when done

The wrong pattern calls both `hasNext()` and `next()` in every iteration, doubling your method calls. Since `next()` returns false when no more records exist, the `hasNext()` check is completely unnecessary.

Gotchas

Calling `hasNext()` before `query()` always returns `false` because no result set exists yet, which can cause logic errors in conditional statements.

The method may trigger additional database queries if called when the result set isn't fully cached, potentially impacting performance in large datasets.

Record permissions checked by ACLs can change between `hasNext()` returning `true` and the subsequent `next()` call, causing `next()` to skip records.

Using `while (gr.hasNext()) { gr.next(); }` doubles your method calls per iteration compared to `while (gr.next()) { }` with no functional benefit.

The result can change between `hasNext()` calls if other transactions modify underlying data during your iteration, leading to inconsistent behavior.

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