ServiceNow Xanadu: The Most Important New Features for Developers and Admins

// Old pattern
var gr = new GlideRecord('incident');
gr.addEncodedQuery('active=true^priority=1');
gr.query();
while (gr.next()) {
    var num = gr.getValue('number');
    var caller = gr.getValue('caller_id');
}

// Xanadu recommended pattern
new GlideQuery('incident')
    .where('active', true)
    .where('priority', 1)
    .select('number', 'caller_id')
    .forEach(function(incident) {
        // incident.number and incident.caller_id are plain strings
    });

Xanadu upgrade considerations for existing instances

Upgrading to Xanadu from an earlier release requires the same preparation as any major ServiceNow upgrade: run an Instance Scan on your pre-upgrade instance to identify potential conflicts, clone production to a test instance, apply the upgrade on the test instance first, and validate critical Business Rules, integrations, and workflows before approving the production upgrade.

Xanadu-specific considerations:

• GlideQuery is now production-recommended — existing GlideRecord scripts do not break, but any new scripts should use GlideQuery for tables where the cleaner syntax is preferred
• Enhanced Flow Designer error handling — existing flows using workaround error handling patterns should be reviewed and may benefit from refactoring to use the new Error Handler step type
• Now Assist plugin activation — Xanadu includes the base Now Assist plugins but they must be explicitly activated. They do not auto-activate on upgrade.
• RaptorDB migration — if your instance is being migrated to RaptorDB, ServiceNow manages this separately and it does not affect the application upgrade process

Related: Cloning instances for pre-upgrade testing · Instance Scan for upgrade readiness · Update Sets for change management around the upgrade

GlideQuery patterns to adopt in Xanadu

With GlideQuery now production-recommended in Xanadu, here is a practical comparison of equivalent GlideRecord and GlideQuery patterns to help you adopt the new API in new code:

// GlideRecord — traditional (still works, still valid)
var gr = new GlideRecord('incident');
gr.addEncodedQuery('active=true^priority=1');
gr.query();
var results = [];
while (gr.next()) {
    results.push({
        number: gr.getValue('number'),
        state: gr.getValue('state'),
        assigned: gr.getDisplayValue('assigned_to')
    });
}

// GlideQuery — Xanadu recommended for new code
var results = new GlideQuery('incident')
    .where('active', true)
    .where('priority', 1)
    .select('number', 'state', 'assigned_to')
    .toArray(100); // returns plain JS objects directly
// results[0].number is a plain string — no getValue() needed

GlideQuery's advantage is clarity — results are plain JavaScript objects, fields are plain strings, and the method chain reads like the intent. The limitation: GlideQuery does not yet support all the edge cases that GlideRecord handles (complex encoded queries with JavaScript expressions, some aggregate patterns). For new straightforward queries, use GlideQuery. For existing code and complex queries, GlideRecord remains the safe choice.

Flow Designer error handling — the practical change

Before Xanadu, handling errors in Flow Designer REST calls required workarounds: branching on a response code variable, using a subflow that returns a status, or accepting that failed API calls would either halt the flow or silently continue. The new Error Handler step type in Xanadu makes this explicit:

// Flow structure with Error Handler
[Trigger] → [Try block]
    → [REST step: Call External API]
    → [Action step: Process Response]
[Catch block]
    → [Log error to custom table]
    → [Create incident for integration failure]
    → [Notify on-call engineer]

Every Flow Designer integration that calls external REST APIs should be reviewed and updated to use the Error Handler pattern in Xanadu. Flows without error handling silently fail or halt in ways that are difficult to diagnose. See Flow Designer error handling guide for implementation details.

Security improvements in Xanadu

Xanadu includes several security improvements relevant to developers and admins. Cross-Site Scripting (XSS) protection enhancements restrict certain previously-allowed patterns in UI scripts and Client Scripts — if your instance has older Client Scripts that manipulate DOM directly, these may need review. Scoped application ACL enforcement is stricter in Xanadu — cross-scope access that previously worked through an oversight may now throw explicit access errors. Run your full regression test suite on a clone before upgrading production. The Instance Scan security category is particularly valuable post-Xanadu-upgrade as it surfaces ACL gaps that the stricter enforcement will now catch at runtime.

Now Assist in Xanadu — the activation path

Xanadu is the minimum release required for all Now Assist capabilities. If your instance is on a pre-Xanadu release, Now Assist is not available regardless of entitlement. After upgrading to Xanadu, follow the activation guide to enable specific capabilities. The base Now Assist Platform plugin (com.sn_now_assist) must be activated first, followed by feature-specific plugins for ITSM, developer, and HR capabilities. Activation does not happen automatically on upgrade — it requires explicit admin action.

Related: Australia release (next release) · RaptorDB · Now Assist activation · Cloning for upgrade testing

NowSpectrum covers every major area of the ServiceNow platform with practical articles written by people who build on it daily. The platform evolves quickly and staying current on releases, new APIs, and best practices is essential for practitioners who advise clients, lead implementations, or work toward senior developer and architect roles. Each release brings new capabilities worth understanding and previous patterns worth reviewing. Use the NowSpectrum article library as your reference for both new features and foundational platform knowledge. The free weekly newsletter delivers one practical tip per week

Xanadu in context — where it sits in the release history

Xanadu is significant because it is the first release where AI capabilities (Now Assist) moved from preview to generally available, and where RaptorDB became the default database engine for new instances. These two changes together define what "modern ServiceNow" means in 2025–2026. Organisations still on pre-Xanadu releases are missing both the performance improvements and the AI capabilities. If your organisation is not yet on Xanadu, the upgrade planning process should treat it as a high priority — the gap between Xanadu and older releases is larger than a typical release gap. The cloning guide covers the pre-upgrade testing workflow, and the Australia release guide covers the following release you will be moving toward after Xanadu.

Xanadu is the baseline for modern ServiceNow in 2025–2026. If your instance is not yet on Xanadu, prioritise the upgrade path. If you are already on Xanadu, the Australia release guide covers the next step. For practitioners evaluating Xanadu features for their organisation, the Now Assist activation guide and implementation strategy are the most immediately actionable guides in the Xanadu feature set.

Xanadu marks the transition from "ServiceNow with AI features" to "AI-native ServiceNow." Every practitioner working on Xanadu and later releases operates in a fundamentally different platform than pre-Xanadu. The scripting fundamentals have not changed — GlideRecord, Business Rules, Flow Designer — but the context in which they operate, and the capabilities available above them, are substantially richer. Invest the time to understand what Xanadu adds; it is one of the more significant release milestones in the platform's history.