GlideRecord.chooseWindow()

What It Does

The chooseWindow() method configures a GlideRecord query to return only a specific range of rows from the result set. The method takes two zero-indexed parameters that define an inclusive window of records to retrieve. When you call query() after setting the window, ServiceNow's database layer applies both the WHERE clause filters and the row limit logic at the SQL level.

Internally, ServiceNow translates the chooseWindow() parameters into database-specific pagination syntax (LIMIT/OFFSET for MySQL, ROW_NUMBER() for Oracle/SQL Server). The platform calculates the offset as firstRow and the limit as (lastRow - firstRow + 1). This happens before any records are retrieved into memory, making it genuinely efficient for large datasets rather than a client-side filter.

The method returns void and only modifies the internal state of the GlideRecord object. The window configuration persists until you create a new GlideRecord instance or call chooseWindow() again with different parameters. If you call query() multiple times on the same GlideRecord instance, each execution applies the same window unless explicitly changed.

Edge cases include requesting a window beyond the available record count, which simply returns fewer records than the window size without throwing an error. Setting firstRow greater than lastRow results in no records returned. The method does not validate parameter types at call time but will cause runtime errors if non-numeric values are passed.

Unlike setLimit() which only controls the maximum number of records returned, chooseWindow() provides both offset and limit functionality. The two methods can be used together, but chooseWindow() takes precedence for determining the actual result set size.

When to Use This

Use chooseWindow() when processing large datasets that would exceed ServiceNow's memory limits or script execution timeouts. Scheduled jobs that need to process thousands of records should chunk the work into manageable windows of 500-1000 records. Data synchronization scripts that need to process records in predictable batches also benefit from this approach, especially when maintaining processing state between executions.

Avoid using chooseWindow() for small result sets where you simply want the top N records—use setLimit() instead for better performance and clearer intent. Don't use it in client-side scripts (it's server-side only), and avoid it in Business Rules that fire frequently since the pagination logic adds overhead to every query execution.

Common misuse includes trying to implement real-time pagination for end users—this method is designed for batch processing, not interactive UI pagination. ServiceNow's list views handle user pagination automatically, and attempting to replicate this behavior with chooseWindow() in GlideAjax or other user-facing code creates unnecessary complexity and performance issues.

Return Value

The method returns void (undefined in JavaScript terms) and serves purely as a configuration method. You cannot chain it with other GlideRecord methods, and attempting to use its return value in conditional statements will always evaluate to false. The actual effect of calling this method only becomes apparent when you subsequently call query() and iterate through the results.

The method does not fail gracefully with invalid parameters—passing non-numeric values or negative numbers will cause runtime errors during query execution, not during the chooseWindow() call itself. Always validate your parameters before calling this method to avoid cryptic database errors during batch processing jobs.

Platform Behavior & Side Effects

• Business Rules, ACLs, and other query interceptors still fire normally for each record returned within the window—the method only affects which records are retrieved, not how they're processed
• No data is written to the database—this is a read-only configuration that only affects subsequent query operations on the same GlideRecord instance
• Performance is significantly better than retrieving all records and filtering in JavaScript—the database handles pagination at the SQL level using optimized indexes
• Query result caching is limited to the specific window requested—different windows of the same query are cached separately, potentially increasing memory usage
• Behavior is identical across all server-side contexts (Business Rules, Script Includes, Scheduled Jobs)—no special handling based on execution context
• Transaction boundaries are respected—if called within a database transaction, the windowed query participates in the same transaction and sees uncommitted changes