GlideRecord.canWrite() — ServiceNow API

canWrite()→ boolean

intermediateTested on Xanadu

What It Does

The canWrite() method performs a read-only evaluation of write permissions for the current GlideRecord. It checks table-level ACLs, field-level security rules, and any custom security constraints without modifying data or triggering update-related Business Rules.

Internally, ServiceNow evaluates the same ACL conditions that would be checked during an actual update() operation, including role-based permissions, conditional ACLs, and field-level restrictions. The evaluation happens in the context of the current user session, respecting role inheritance and elevated privileges.

The method returns true if the user can write to the record, false if write access is denied. Unlike canRead(), this method never returns null or undefined values.

The permission check evaluates against the specific record currently loaded in the GlideRecord, not just table-level permissions. This means conditional ACLs based on field values, assignment rules, or custom scripts are properly evaluated. If no record is loaded (before get() or next()), the method returns false.

Related methods in the GlideRecord class include canRead() for read permissions, canCreate() for insert permissions, and canDelete() for delete permissions. Each method evaluates different ACL operation types and should be used for their specific use cases.

When to Use This

Use canWrite() before any setValue() or update() operations in server-side scripts where the current user context matters. This is especially critical in Business Rules, Script Includes called from client-side, and Scheduled Jobs that impersonate users. Without this check, ACL violations fail silently, leaving you debugging why records aren't updating.

Don't use canWrite() for create operations—use canCreate() instead. Avoid this method in before Business Rules where you're the system making changes—the permission check reflects the triggering user, not the system context. Skip permission checks entirely when using setWorkflow(false) since you're explicitly bypassing security.

⚠️

In after Business Rules, canWrite() evaluates permissions against the NEW field values, not the original values that triggered the rule.

Return Value

Returns a boolean value: true if the current user has write access to the loaded record, false if access is denied or no record is loaded. The method never throws exceptions or returns null, making it safe to use directly in conditional statements without additional null checks.

When no record is currently loaded in the GlideRecord (before calling get() or next()), the method returns false since there's no specific record context to evaluate permissions against. Always ensure a record is loaded before relying on this method for permission decisions.

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

Triggers ACL evaluation scripts but does not fire Business Rules, Workflows, or send notifications
Does not write anything to the database or create audit entries
Performance is moderate—ACL script evaluation can be expensive with complex conditional logic
ACL results may be cached within the same session, but permission changes during script execution are reflected immediately
Evaluates permissions in the context of the current user session, including impersonation and elevated privileges
In Business Rules, evaluates against the user who triggered the rule, not the system context
Script Include functions called via AJAX inherit the client user's permissions, making this check essential

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 permission check before updatebasic

// Safely update incident priority with permission check
var inc = new GlideRecord('incident');
inc.get('9d385017c611228701d22104cc95c371');

if (inc.canWrite()) {
    inc.setValue('priority', '1');
    inc.setValue('comments', 'Escalated due to business impact');
    inc.update();
    gs.info('Incident priority updated successfully');
} else {
    // Log the permission failure for debugging
    gs.warn('User ' + gs.getUserName() + ' cannot write to incident ' + inc.number);
    // Handle the denial gracefully
    gs.addErrorMessage('Insufficient permissions to update this incident');
}

This pattern prevents silent failures when ACLs block the update. The permission check happens before any setValue calls, avoiding wasted processing when the update will fail.

Bulk update with permission filteringintermediate

// Update multiple incidents but skip ones without write access
var incidents = new GlideRecord('incident');
incidents.addQuery('state', '1'); // New incidents
incidents.addQuery('priority', '5'); // Low priority
incidents.query();

var updated = 0, skipped = 0;
while (incidents.next()) {
    if (incidents.canWrite()) {
        incidents.setValue('priority', '4'); // Medium-Low
        incidents.update();
        updated++;
    } else {
        skipped++;
    }
}

gs.info('Updated ' + updated + ' incidents, skipped ' + skipped + ' due to permissions');

When processing multiple records, permission checks prevent partial failures and provide clear feedback about which records were skipped. This pattern is essential for user-triggered bulk operations.

The classic mistake—checking after setValueadvanced

// WRONG: Checking permissions after setValue calls
var inc = new GlideRecord('incident');
inc.get('9d385017c611228701d22104cc95c371');

// These setValue calls waste CPU cycles
inc.setValue('priority', '1');
inc.setValue('comments', 'Escalated');

// Permission check comes too late
if (inc.canWrite()) {
    inc.update(); // Might still fail due to field-level ACLs
}

// RIGHT: Check permissions first
var inc2 = new GlideRecord('incident');
inc2.get('9d385017c611228701d22104cc95c371');

if (inc2.canWrite()) {
    inc2.setValue('priority', '1');
    inc2.update();
}

Checking permissions after setValue wastes processing and doesn't catch field-level ACL violations. The permission check evaluates table-level access, but individual field ACLs are checked during update regardless.

Gotchas

The method returns false when no record is loaded, even if the user has table-level write permissions—always call get() or next() first.

In after Business Rules, canWrite() evaluates against the current field values in the GlideRecord, which may differ from the original values that triggered the rule.

Field-level ACLs are not evaluated by canWrite()—the method only checks table-level write permissions, so update() can still fail on individual fields.

When using setWorkflow(false), permission checks become meaningless since you're bypassing all security—skip canWrite() in these scenarios.

Script Includes called via AJAX inherit the web session user's permissions, not the system context, making canWrite() checks essential for client-triggered server operations.

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