GlideRecord.getEncodedQuery()

getEncodedQuery()→ string

intermediateTested on Xanadu

What It Does

The getEncodedQuery() method extracts all current query conditions from a GlideRecord instance and returns them as a single encoded query string. This encoded string uses ServiceNow's standard query syntax with operators like ^ for AND conditions and ^OR for OR conditions.

Internally, ServiceNow maintains query conditions in a structured format as you call addQuery(), addEncodedQuery(), or addNullQuery(). When you call getEncodedQuery(), the platform serializes these conditions back into the URL-encoded string format that you see in list view filters and can paste into addEncodedQuery().

The method returns a string containing the encoded query, or an empty string if no query conditions have been set. It never returns null or undefined. The returned string is immediately usable in another GlideRecord's addEncodedQuery() method or can be logged for debugging purposes.

Edge cases include queries with chooseWindow() applied - the windowing is not included in the encoded query since it's a result limitation, not a filter condition. Similarly, orderBy() sorting is not captured because encoded queries only represent WHERE clause conditions, not ORDER BY or LIMIT clauses.

This method is the inverse of addEncodedQuery() - where addEncodedQuery() takes an encoded string and adds it to the query conditions, getEncodedQuery() extracts all current conditions as an encoded string. It's also related to getRowCount() in that both methods operate on the current query state without executing the query.

When to Use This

Use getEncodedQuery() when debugging complex queries that aren't returning expected results, especially when the query was built programmatically with multiple addQuery() calls or when combining user input with programmatic filters. It's essential for logging and troubleshooting in Business Rules and Script Includes where you can't easily see what query was constructed. Another common use case is copying query conditions from one GlideRecord to another, particularly when you need to apply the same filter logic to different tables or in different contexts.

Don't use this method when you need to examine individual query conditions separately - getEncodedQuery() returns everything as one concatenated string. If you need to inspect or modify specific conditions, you'll need to parse the encoded query string yourself or restructure your code to track conditions separately. Also avoid using this for performance optimization - the method itself is fast, but if you're calling it repeatedly in loops, you're probably overcomplicating your query logic.

⚠️

Don't assume the returned encoded query string will remain in the same format across ServiceNow versions. The encoding logic can change between releases, so avoid parsing the string programmatically unless absolutely necessary.

Return Value

Returns a string containing the URL-encoded query in ServiceNow's standard format. Field names and values are connected with operators like =, !=, CONTAINS, and multiple conditions are joined with ^ for AND or ^OR for OR logic.

When no query conditions have been applied to the GlideRecord, the method returns an empty string ''. The return value is always safe to use in string operations without null checking, and can be directly passed to another GlideRecord's addEncodedQuery() method even when empty.

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 database interaction occurs - this method only examines the in-memory query state of the GlideRecord instance
No Business Rules, Script Engines, or notifications are triggered since no data access happens
Performance is very fast - the method operates entirely on objects already in memory
ACL checks are not performed since no records are accessed or evaluated
The method can be called safely from any server-side context including before/after Business Rules and Script Includes
No session state or user context affects the return value - it purely reflects the programmatic query conditions
The query state remains unchanged - calling this method does not modify the GlideRecord's query conditions in any way

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 debugging — inspect what your query actually containsbasic

// Build a complex query programmatically
var gr = new GlideRecord('incident');
gr.addQuery('state', '!=', 7);
gr.addQuery('priority', 1);
gr.addEncodedQuery('assigned_to!=NULL^caller_id.company=javascript:getMyCompany()');

// See exactly what query was built
var currentQuery = gr.getEncodedQuery();
gs.info('Current query: ' + currentQuery);

// Execute the query
gr.query();
gs.info('Found ' + gr.getRowCount() + ' records');

// Output will show: state!=7^priority=1^assigned_to!=NULL^caller_id.company=javascript:getMyCompany()

This demonstrates the primary debugging use case - understanding exactly what query conditions have been applied when building complex filters programmatically. Essential when your query isn't returning expected results.

Intermediate — copy query conditions between GlideRecord instancesintermediate

// Build query conditions on one GlideRecord
var sourceGR = new GlideRecord('incident');
sourceGR.addQuery('active', true);
sourceGR.addQuery('assignment_group.name', 'CONTAINS', 'Network');
sourceGR.addNullQuery('resolved_at');

// Extract and apply to different table
var queryString = sourceGR.getEncodedQuery();
var targetGR = new GlideRecord('problem');
targetGR.addEncodedQuery(queryString);

// Add table-specific conditions
targetGR.addQuery('state', '!=', 'Closed');

gs.info('Applied query: ' + targetGR.getEncodedQuery());
targetGR.query();

Shows how to transfer query logic between different GlideRecord instances, useful when you need to apply similar filtering logic across multiple tables or contexts within the same script.

Advanced — conditional query building with validationadvanced

// Function that builds queries based on user parameters
function buildFilteredQuery(tableName, userFilters, securityContext) {
    var gr = new GlideRecord(tableName);
    
    // Apply base security filter
    gr.addQuery('sys_created_by', securityContext.userId);
    
    // Apply user filters conditionally
    if (userFilters.status) {
        gr.addQuery('state', userFilters.status);
    }
    
    // Log the complete query for audit purposes
    var finalQuery = gr.getEncodedQuery();
    gs.info('User ' + securityContext.userId + ' executing query: ' + finalQuery);
    
    // Validate query complexity (prevent performance issues)
    if (finalQuery.split('^').length > 10) {
        throw new Error('Query too complex: ' + finalQuery);
    }
    
    return gr;
}

Demonstrates using getEncodedQuery() for query validation and audit logging in dynamic query building scenarios. The encoded query becomes a security and performance checkpoint before execution.

Gotchas

The encoded query only includes WHERE clause conditions - it does not capture orderBy(), chooseWindow(), or setLimit() settings applied to the GlideRecord.

Query conditions added after calling query() but before calling next() are still captured by getEncodedQuery(), even though they won't affect the current result set.

JavaScript business rule queries that include 'javascript:' functions in the encoded string will execute those functions when the query runs, potentially causing unexpected side effects.

Empty string conditions (like addQuery('field', '')) appear in the encoded query as 'field=' which is different from addNullQuery('field') which appears as 'field=NULL'.

OR query groups created with addQuery('field', 'IN', 'value1,value2') appear as 'field=value1^ORfield=value2' in the encoded string, not as a single IN clause.

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