GlideRecord.getRecordClassName()

getRecordClassName()→ string

intermediateTested on Xanadu

What It Does

The getRecordClassName() method returns the actual table name where the current record resides in the database. This becomes crucial when working with table hierarchies where records from extended tables can be retrieved through queries on their parent tables.

Internally, ServiceNow maintains table inheritance through the sys_class_name field on every record in extended tables. When you call this method, it reads that field value to determine which specific table the record belongs to, then returns that table's name as a string.

The method always returns a string containing the table name, never null or empty. If called on a record from a base table with no extensions, it returns the same value as getTableName(). The return value matches exactly what you see in the Table Name field of the table's dictionary record.

An important edge case occurs when working with records that have been moved between tables through table splits or merges. The method still returns the current table name based on the sys_class_name field, which gets updated during these operations.

This method differs fundamentally from getTableName(), which returns the table you queried against. It also differs from getClassName(), which returns the JavaScript class name rather than the database table name.

When to Use This

Use getRecordClassName() when you need to perform different logic based on the specific table type of a record, especially when iterating through results from a base table query. Common scenarios include processing task records where you need different handling for incidents versus changes, or working with configuration item records where behavior varies by CI type.

Avoid this method when you simply need the name of the table you're currently working with - use getTableName() instead. Also avoid it for building queries or API calls where you need the base table name, as those operations expect the parent table name, not the extended table name.

A common misuse pattern involves using this method for table validation or security checks. These should typically use getTableName() instead, since access controls and business rules are usually configured at the base table level.

Return Value

Returns a string containing the exact table name as defined in the database schema. The string is never null, empty, or undefined - even for invalid or deleted records, it returns the table name stored in the record's sys_class_name field.

The returned string can be safely used for string comparisons, building GlideRecord queries on the specific table, or constructing REST API endpoints. However, be cautious when using it to build queries that should include related table types - in those cases, query the base table instead.

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, ACLs, or notifications are triggered - this is a simple field read operation
Nothing is written to the database - the method only reads the existing sys_class_name field value
Performance is very fast since it reads from an already-loaded field in memory
The result is not cached separately - each call reads the field value fresh
Behavior is identical across all server-side contexts including business rules, script includes, and scheduled jobs
Works correctly even on records loaded through encoded queries or complex joins
Returns accurate results even when called multiple times on the same record instance

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 usage with task table hierarchybasic

// Query the base task table to get all types of tasks
var taskGR = new GlideRecord('task');
taskGR.addQuery('active', true);
taskGR.query();

while (taskGR.next()) {
    var queryTable = taskGR.getTableName();     // Always 'task'
    var actualTable = taskGR.getRecordClassName(); // Could be 'incident', 'change_request', etc.
    
    gs.info('Queried: ' + queryTable + ', Actual: ' + actualTable + 
            ', Number: ' + taskGR.getValue('number'));
    
    // Different logic based on actual table type
    if (actualTable === 'incident') {
        // Handle incident-specific processing
        gs.info('Processing incident: ' + taskGR.getValue('number'));
    } else if (actualTable === 'change_request') {
        // Handle change-specific processing  
        gs.info('Processing change: ' + taskGR.getValue('number'));
    }
}

This example shows the key difference between getTableName() and getRecordClassName() when querying a base table. The query table stays constant while the actual table varies by record type.

Dynamic GlideRecord creation for specific table typesintermediate

// Process CI records but handle each type differently
var ciGR = new GlideRecord('cmdb_ci');
ciGR.addQuery('install_status', '1'); // Installed
ciGR.query();

var processedTables = {};

while (ciGR.next()) {
    var actualTable = ciGR.getRecordClassName();
    
    // Track which table types we're processing
    if (!processedTables[actualTable]) {
        processedTables[actualTable] = 0;
    }
    processedTables[actualTable]++;
    
    // Create a new GlideRecord for the specific table to access extended fields
    var specificGR = new GlideRecord(actualTable);
    if (specificGR.get(ciGR.getUniqueValue())) {
        // Now we can access table-specific fields safely
        gs.info('Processing ' + actualTable + ': ' + specificGR.getValue('name'));
        
        // Table-specific field access that wouldn't work on base table
        if (actualTable === 'cmdb_ci_server') {
            gs.info('Server OS: ' + specificGR.getValue('os'));
        }
    }
}

// Report summary of processed table types
for (var table in processedTables) {
    gs.info('Processed ' + processedTables[table] + ' records from ' + table);
}

This pattern uses getRecordClassName() to identify specific table types, then creates targeted GlideRecord objects to safely access extended fields not available on the base table.

The classic mistake - using for access control checksadvanced

// WRONG - Don't do this for security checks
var taskGR = new GlideRecord('task');
if (taskGR.get('INC0000123')) {
    var actualTable = taskGR.getRecordClassName(); // Returns 'incident'
    
    // This security check will fail because user has 'task' role, not 'incident' role
    if (!gs.hasRole('admin') && !gs.hasRole(actualTable)) {
        gs.addErrorMessage('No access to ' + actualTable + ' records');
        return;
    }
}

// RIGHT - Use the queried table for security
var taskGR2 = new GlideRecord('task');
if (taskGR2.get('INC0000123')) {
    var queryTable = taskGR2.getTableName(); // Returns 'task'
    
    // This works because ACLs and roles are typically configured on base tables
    if (!gs.hasRole('admin') && !gs.hasRole(queryTable + '_user')) {
        gs.addErrorMessage('No access to task records');
        return;
    }
    
    // Use getRecordClassName() only for processing logic, not security
    var actualTable = taskGR2.getRecordClassName();
    gs.info('Processing ' + actualTable + ' via ' + queryTable + ' permissions');
}

Security checks should use getTableName() because permissions are granted at the base table level. Using getRecordClassName() for access control will often fail even when the user has proper permissions.

Gotchas

The method returns the extended table name even when you don't have direct access to that table - it only reads the sys_class_name field from the already-loaded record.

Using getRecordClassName() in ACL scripts or security checks often fails because roles and permissions are typically granted on base tables, not extended tables.

The returned table name may not match the table you queried against, which can break code that assumes they're the same when building related queries.

When working with table hierarchies, some extended table fields may not be accessible through the original GlideRecord object even after calling getRecordClassName() - you need to create a new GlideRecord for the specific table.

The method works on deleted records and returns their original table name, but attempting to query that table directly with the record's sys_id may fail if the record has been moved or archived.

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