Background Scripts
Report Active Locked-out Users
List active user accounts whose local locked_out flag is set, for manual access troubleshooting without unlocking accounts or changing security settings.
(function reportLockedOutUsers() {
var prefix = '[SN-Tricks:LockedOutUsers]';
var limit = 100;
try {
var users = new GlideRecord('sys_user');
users.addQuery('active', true);
users.addQuery('locked_out', true);
users.orderBy('sys_id');
users.setLimit(limit + 1);
users.query();
var shown = 0;
var truncated = false;
while (users.next()) {
if (shown >= limit) {
truncated = true;
break;
}
gs.info(prefix + ' user=' + users.getUniqueValue());
shown++;
}
gs.info(prefix + ' Reported ' + shown + ' active locked-out user(s).' +
(truncated ? ' More matches exist; output capped at ' + limit + '.' : ' All matching users shown.'));
} catch (error) {
gs.error(prefix + ' Report failed; disregard partial output: ' + error);
}
})();How to use it
1. As an authorized administrator, open System Definition > Scripts - Background in a non-production instance and select Global scope. This custom diagnostic uses the OOB sys_user table. Keep limit a positive whole number. No cross-scope access is required in Global. 2. Paste and run the script. Search output or system logs for [SN-Tricks:LockedOutUsers]. It queries Active is true AND Locked out is true, orders by sys_id, and prints at most 100 user identifiers. One extra result detects truncation; the count is not a total when capped. User names, email addresses, passwords, and authentication data are not logged. 3. In sub-production, prepare dedicated test users covering all four combinations of active and locked_out. Only active=true, locked_out=true should appear. Do not lock your own administrator account or a real service account to create test data. Compare with the sys_user list using the same filters and domain context. 4. Test zero, exactly 100, and 101 matching rows. Only the 101-row case should warn of truncation. Verify that no account fields change. Local mock tests cover filtering, stable ordering, output limits, and query/read exceptions, but do not prove behavior on a ServiceNow instance. 5. This reports the local locked_out flag only. It does not establish the cause, duration, or legitimacy of a lock, inspect identity-provider lockouts or SSO policy, or prove whether a user can authenticate. Locked accounts can be intentionally restricted; never unlock solely from this report. Review under your normal identity/security process. 6. Administrative GlideRecord is not an ACL-filtered end-user report. Domain separation, query business rules, and concurrent changes affect results. Internal identifiers remain sensitive. A row cap limits output, not database scan cost; evaluate runtime with representative data before production use. 7. On any error, disregard partial output. There are no inserts, updates, deletes, unlocks, or notifications; no data rollback is needed. Ad hoc execution creates no reusable configuration to promote in an update set. Any later scheduled-job adaptation needs a separate access, scheduling, and update-set review.
Adapt the table names, fields, and conditions to your instance. Test the behavior in a development environment before using it in production.