sys_user Table — ServiceNow Reference

Table Reference/sys_user

The sys_user table contains all user accounts, profiles, and authentication data in ServiceNow. Part of the core Platform, it's referenced by virtually every other table through assignment fields, approvals, and audit columns. Key gotcha: active status doesn't mean what you think — check locked_out and web_service_access_only flags too.

What This Table Is

The sys_user table is the master repository for all user accounts in ServiceNow. It stores authentication credentials, personal information, organizational details, preferences, and access controls for every person who can log into the system. This includes employees, contractors, customers, vendors, and service accounts.

Owned by the Platform module, this table supports every ServiceNow process — ITSM, ITOM, SecOps, HR, CSM. It's the authoritative source for user identity across all applications. User records drive role-based access control, assignment logic, approval workflows, and audit trails throughout the platform.

The sys_user table extends sys_person, which provides basic contact information shared with non-user person records like customers in CSM. No tables extend sys_user directly — it's the leaf table for all authenticated users.

In large enterprises, expect 50,000 to 200,000+ user records. The table performs well for individual lookups but can be expensive for complex queries without proper filtering on indexed fields like active, user_name, employee_number, or department.

When You'll Script Against This Table

You'll hit sys_user in Business Rules validating assignments, Script Includes for user lookups, UI Policies controlling field visibility based on user attributes, Transform Maps during user imports, and Scheduled Jobs for bulk user updates. Client Scripts frequently query user preferences and profile data for form customization.

User table access is controlled by the user_admin role for full CRUD operations. Most users can read their own record and basic directory information on others. Sensitive fields like user_password and ldap_server have additional ACL restrictions.

Common scripting patterns:

Lookup users by user_name or employee_number for assignment validation
Filter by department, location, or manager for bulk operations
Check active status before assignments or notifications
Validate user roles for access control in custom applications
Update user preferences and profile data during onboarding
Query manager hierarchies for approval workflow routing
Sync user data with external systems via Transform Maps and Web Services

Table Gotchas

⚠️

The active field only controls login access. Users marked active=false can still be assigned to records, receive notifications, and appear in reference fields. Check locked_out and web_service_access_only for complete access status.

⚠️

The user_name field is case-sensitive in queries but case-insensitive for login. Use .toLowerCase() when comparing user names in scripts to avoid false negatives.

Email addresses in email field aren't unique by default — multiple users can share the same email, breaking notification logic
The manager field can create circular references — always check for infinite loops in approval hierarchies

⚠️

Avoid queries with .startsWith() on name fields without additional filters. They bypass indexes and timeout on large datasets. Use employee_number or user_name instead.

LDAP users have source set to 'ldap' — updating certain fields on these records gets overwritten on next sync
User records with web_service_access_only=true can authenticate via API but can't log into the UI — critical for integration user setup

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.

The sys_user table extends sys_person, inheriting basic contact fields like first_name, last_name, email, and phone. The person table supports non-user contacts in Customer Service Management.

Most table relationships involve sys_user_group for team assignments, sys_user_role for access control, task table assignments (assigned_to, caller_id), and sysapproval_approver for approval workflows. These joins are extremely common in reporting and assignment logic.

Location-based queries frequently join cmn_location via the location field for regional assignments. Department-based filtering uses cmn_department for organizational reporting and access controls. The sys_user_has_role many-to-many table connects users to roles for security evaluations.

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

Key Fields

Column	Type	Label	Notes
user_name	string	User ID	Unique login identifier. Case-sensitive in queries but case-insensitive for authentication — causes confusion in script comparisons.
active	boolean	Active	Controls login access only. Inactive users can still be assigned to records and receive notifications — check other status fields too.
locked_out	boolean	Locked out	Account locked due to failed login attempts or admin action. Takes precedence over active status for access decisions.
web_service_access_only	boolean	Web service access only	User can authenticate via REST/SOAP but cannot access the UI. Critical for integration service accounts.
employee_number	string	Employee number	Often used as unique identifier in HR integrations. Indexed for performance but can be null for contractors or external users.
email	email	Email	Primary email address for notifications. Not unique by default — multiple users can share emails, breaking notification delivery logic.
department	reference	Department	References cmn_department table. Commonly used for assignment rules and reporting. Can be null for external users.
manager	reference	Manager	Self-referencing to sys_user. Can create circular hierarchies — always validate manager chains to prevent infinite loops in approvals.
location	reference	Location	References cmn_location table. Used for regional assignment rules and asset management. Often drives timezone calculations.
source	string	Source	Identifies user origin: 'ldap', 'okta', etc. LDAP users get overwritten on sync — check before manual updates.
time_zone	string	Time zone	User's timezone preference for date/time display. Critical for SLA calculations and scheduled notifications across regions.
roles	user_roles	Roles	Comma-separated role list field. Read-only display — actual role assignments stored in sys_user_has_role table.
groups	glide_list	Groups	Shows group memberships from sys_user_grmember table. Updates here don't persist — manage via group membership records directly.
last_login_time	glide_date_time	Last login	System-updated timestamp of last successful login. Useful for identifying inactive accounts in cleanup scripts.
failed_attempts	integer	Failed attempts	Count of consecutive failed login attempts. Auto-resets on successful login. Used for account lockout policies.
ldap_server	reference	LDAP server	References ldap_server_config for LDAP-sourced users. Determines sync behavior and password policies.
vip	boolean	VIP	Marks high-priority users for special handling in incidents and requests. Often drives SLA and assignment rules.
cost_center	reference	Cost center	References cmn_cost_center for financial tracking. Used in approval workflows and cost allocation for services and assets.

Common Queries

Get all active users

// Most basic query - what every developer tries first
var gr = new GlideRecord('sys_user');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    // Process active users
    // Remember: active != full access - check locked_out too
    gs.info('Active user: ' + gr.user_name + ' (' + gr.email + ')');
}

Find users by department who can actually log in

// Real-world query checking multiple access flags
var gr = new GlideRecord('sys_user');
gr.addQuery('department.name', 'IT');
gr.addQuery('active', true);
gr.addQuery('locked_out', false);
gr.addQuery('web_service_access_only', false); // Exclude API-only accounts
gr.query();

gs.info('Found ' + gr.getRowCount() + ' IT users who can access UI');
while (gr.next()) {
    gs.info(gr.first_name + ' ' + gr.last_name + ' - ' + gr.user_name);
}

Get manager hierarchy for approval routing

// Business scenario: walk up manager chain for approvals
function getManagerChain(userSysId, maxLevels) {
    var managers = [];
    var gr = new GlideRecord('sys_user');
    gr.get(userSysId);
    
    var currentUser = gr;
    var level = 0;
    
    // Prevent infinite loops in circular manager hierarchies
    while (currentUser.manager && level < maxLevels) {
        currentUser = new GlideRecord('sys_user');
        currentUser.get(gr.manager);
        if (currentUser.isValidRecord()) {
            managers.push(currentUser.sys_id.toString());
        }
        level++;
    }
    return managers;
}

Count users by department using GlideAggregate

// Aggregate count for reporting dashboard
var ga = new GlideAggregate('sys_user');
ga.addQuery('active', true);
ga.addNotNullQuery('department');
ga.groupBy('department');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var deptName = ga.department.getDisplayValue();
    var userCount = ga.getAggregate('COUNT');
    gs.info(deptName + ': ' + userCount + ' active users');
}

Gotcha: Wrong way vs right way to find user by name

// WRONG: Case-sensitive comparison fails
var gr = new GlideRecord('sys_user');
gr.addQuery('user_name', 'John.Smith'); // Fails if stored as 'john.smith'
gr.query();

// RIGHT: Case-insensitive comparison
var gr2 = new GlideRecord('sys_user');
gr2.addQuery('user_name', 'STARTSWITH', 'john.smith'.toLowerCase());
gr2.addQuery('user_name', 'ENDSWITH', 'john.smith'.toLowerCase());
gr2.query();

// BETTER: Use GlideRecord's built-in case handling
var gr3 = new GlideRecord('sys_user');
if (gr3.get('user_name', 'John.Smith')) {
    // get() method handles case-insensitive lookup automatically
    gs.info('Found user: ' + gr3.name);
}

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

sys_user