GlideRecord.autoSysFields()

autoSysFields(enable)→ void

advancedTested on Xanadu

What It Does

The autoSysFields() method controls whether ServiceNow's database layer automatically updates system audit fields during insert() and update() operations. When enabled (the default behavior), ServiceNow automatically sets sys_updated_on to the current timestamp, sys_updated_by to the current user's sys_id, and increments sys_mod_count.

Internally, ServiceNow's database abstraction layer checks a flag on the GlideRecord instance before executing the SQL statement. When autoSysFields(false) is called, this flag is disabled, and the platform skips the automatic field updates entirely. The database operation proceeds with whatever values are explicitly set in the GlideRecord, or leaves existing values unchanged if no explicit values were provided.

The method returns void and affects only the current GlideRecord instance. Each GlideRecord maintains its own auto-system-fields flag, so disabling it on one record doesn't affect other GlideRecord instances, even those querying the same table. The setting persists for the lifetime of the GlideRecord object, applying to all subsequent insert() or update() calls.

An important edge case occurs with bulk operations: if you're iterating through multiple records with a single GlideRecord instance, calling autoSysFields(false) once disables auto-updates for all records processed by that instance. The flag doesn't reset between next() iterations. Additionally, the method has no effect on client-side GlideRecord operations or on records modified through the UI—it only applies to server-side database operations.

The method is closely related to setWorkflow(false) and setAbortAction(true) in migration scenarios. While setWorkflow() controls business rules and workflow execution, autoSysFields() operates at a lower level, affecting the database operation itself rather than the business logic layer.

When to Use This

Use autoSysFields(false) primarily during data migrations when you need to preserve the original audit trail from a source system. This is essential when importing historical data where maintaining the original created/updated timestamps and user references is critical for compliance or audit purposes. The method is also valuable in bulk data operations where you're synchronizing records from external systems and need to maintain their original modification metadata.

Avoid using this method in normal business logic or interactive processes where users expect to see accurate "last modified" information. Instead, use setValue() or direct field assignment for regular record updates. Don't use autoSysFields(false) as a way to avoid triggering business rules—use setWorkflow(false) instead, which is the correct method for that purpose.

⚠️

Never disable auto-system-fields in production business processes unless you explicitly manage audit fields yourself. Missing or stale audit information breaks change tracking and can cause compliance issues.

Return Value

The method returns void and cannot fail in the traditional sense—it simply sets an internal flag on the GlideRecord instance. There's no success or failure condition to check, and no return value to validate. The method always completes successfully regardless of the current state of the GlideRecord or the validity of the boolean parameter.

Since there's no return value, you cannot chain this method or use it in conditional statements. The effect of the method is only visible in the behavior of subsequent insert() or update() operations—you must examine the resulting database records to verify that system fields were or were not automatically updated as expected.

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

Business rules, ACLs, and notifications still execute normally—this method only affects automatic system field updates, not the workflow engine
Audit records are still created for the database operation, but they may contain stale or explicitly set system field values rather than current timestamps
Performance impact is minimal—the method simply sets a boolean flag and doesn't involve database queries or complex processing
Works identically in before/after business rules, script includes, and scheduled jobs—the database layer handles the flag consistently across all server-side contexts
When disabled, explicitly setting sys_updated_on, sys_updated_by, or sys_mod_count in your code will write those exact values to the database without platform interference
Client-side GlideRecord operations ignore this method entirely—it only affects server-side database operations executed through the Java database layer
The flag persists across multiple operations on the same GlideRecord instance but resets when you create a new GlideRecord object

Parameters

Name	Type	Required	Description
enable	boolean	Yes	When true (default), ServiceNow automatically updates system audit fields during database operations. When false, preserves existing values of sys_updated_on, sys_updated_by, and sys_mod_count. Setting applies only to the current GlideRecord 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 — preserving audit fields during migrationbasic

// Import incident with original audit trail preserved
var gr = new GlideRecord('incident');
gr.initialize();

// Disable automatic system field updates
gr.autoSysFields(false);

// Set fields including original audit values
gr.short_description = 'Network outage in Building A';
gr.priority = '1';
gr.state = '6'; // Resolved

// Explicitly set the original audit information
gr.sys_created_on = '2024-01-15 09:30:00';
gr.sys_created_by = 'legacy_user_sys_id';
gr.sys_updated_on = '2024-01-15 14:22:00';
gr.sys_updated_by = 'legacy_admin_sys_id';
gr.sys_mod_count = '3';

// Insert preserves the explicitly set audit values
var sys_id = gr.insert();
gs.info('Imported incident ' + sys_id + ' with preserved audit trail');

This example shows the primary use case: importing historical data while maintaining original timestamps and user references. The platform won't overwrite the explicitly set system fields.

Intermediate — bulk update with selective audit controlintermediate

// Update multiple incidents while preserving some audit fields
var gr = new GlideRecord('incident');
gr.addQuery('state', '2'); // In Progress
gr.addQuery('priority', '1'); // High priority
gr.query();

while (gr.next()) {
    // Disable auto-updates to control modification tracking
    gr.autoSysFields(false);
    
    // Business logic update
    gr.assignment_group = 'network_team_sys_id';
    gr.comments = 'Bulk assigned to network team for P1 incidents';
    
    // Keep original sys_updated_on but update sys_updated_by
    // sys_updated_on stays unchanged (preserves original timing)
    gr.sys_updated_by = gs.getUserID(); // Current user takes ownership
    
    gr.update();
}

gs.info('Bulk updated ' + gr.getRowCount() + ' high priority incidents');

This demonstrates selective audit field control during bulk operations. You can preserve some audit fields while explicitly updating others to reflect administrative ownership.

Advanced — the classic mistake with multiple operationsadvanced

// WRONG: Assuming autoSysFields resets between operations
function migrateIncidentsWrong(recordsArray) {
    var gr = new GlideRecord('incident');
    
    for (var i = 0; i < recordsArray.length; i++) {
        var record = recordsArray[i];
        
        if (record.preserveAudit) {
            gr.autoSysFields(false); // This affects ALL subsequent operations
        }
        // BUG: Never re-enable autoSysFields for non-preserve records
        
        gr.initialize();
        gr.short_description = record.description;
        gr.sys_created_on = record.originalDate;
        gr.insert(); // ALL records get preserved audit, not just preserve=true
    }
}

// CORRECT: Explicitly manage the flag for each operation
function migrateIncidentsCorrect(recordsArray) {
    for (var i = 0; i < recordsArray.length; i++) {
        var record = recordsArray[i];
        var gr = new GlideRecord('incident'); // New instance each time
        
        gr.autoSysFields(!record.preserveAudit); // Explicit true/false
        gr.initialize();
        gr.short_description = record.description;
        
        if (record.preserveAudit) {
            gr.sys_created_on = record.originalDate;
        }
        
        gr.insert();
    }
}

The flag persists across multiple operations on the same GlideRecord instance. Create new instances for mixed audit behavior, or explicitly call autoSysFields(true) to re-enable automatic updates.

Gotchas

The autoSysFields flag persists for the entire lifetime of the GlideRecord instance and doesn't reset between next() iterations or after insert/update operations.

Calling autoSysFields(false) has no effect on client-side GlideRecord operations or records modified through the ServiceNow UI—it only applies to server-side database operations.

Business rules and workflow still execute normally when autoSysFields is disabled—use setWorkflow(false) if you need to prevent business rule execution during migrations.

When autoSysFields is disabled, you must explicitly manage all system audit fields yourself or they will contain stale values that can break change tracking and reporting.

The method affects sys_created_on and sys_created_by during insert() operations, not just update fields—disable it only when you're explicitly setting creation audit fields during data imports.

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