GlideRecord.setWorkflow() — ServiceNow API

setWorkflow(enable)→ void

intermediateTested on Xanadu

What It Does

The setWorkflow() method controls Business Rule execution for a specific GlideRecord instance. When you call setWorkflow(false), ServiceNow bypasses all Business Rules that would normally fire during insert(), update(), or deleteRecord() operations on that record.

Internally, ServiceNow sets a flag on the GlideRecord object that the database layer checks before triggering Business Rules. This affects all types of Business Rules: before, after, async, and display. The suppression applies to the current GlideRecord instance only and persists for the lifetime of that object. Other GlideRecord instances remain unaffected.

The method returns void and cannot fail. There's no return value to check because the operation simply sets an internal flag. The workflow setting takes effect immediately and applies to all subsequent database operations on that GlideRecord instance.

The method only affects Business Rules, not other platform mechanisms. ACLs, audit logging, and field validation still execute normally. Notifications triggered directly by Business Rules won't fire, but notifications configured through other means remain unaffected. UI policies and client scripts don't apply since this is a server-side API.

Related methods include autoSysFields() which controls system field updates, and setUseEngines() which controls multiple platform features at once. Unlike setUseEngines(false), setWorkflow(false) provides granular control over just Business Rules.

When to Use This

Use setWorkflow(false) during data migrations, bulk imports, or administrative cleanup operations where Business Rules would interfere with the process. This includes scenarios where Business Rules might trigger notifications, create unwanted child records, or perform expensive calculations that aren't needed during bulk operations. It's also essential when correcting data where Business Rules might prevent necessary updates or cause infinite loops.

Avoid this method for regular application logic where Business Rules should execute normally. If you need to bypass specific Business Rules rather than all of them, modify the Business Rule conditions instead. For broader control over platform features, use setUseEngines(false) which disables Business Rules, audit logging, and other platform mechanisms simultaneously.

Return Value

The method returns void and has no failure conditions to handle. The workflow setting is applied immediately to the GlideRecord instance, and there's no indication of success or failure because the operation cannot fail. Don't attempt to chain this method or use its return value in conditionals.

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 (before, after, async, display) are completely bypassed when workflow is disabled
ACLs continue to execute normally and can still prevent database operations
Audit logging behavior depends on system configuration and may still occur
Performance improves significantly during bulk operations since Business Rule processing is skipped
Notifications triggered by Business Rules won't fire, but other notification mechanisms remain active
Field validation and data integrity checks at the database level still apply
The setting persists for the lifetime of the GlideRecord instance but doesn't affect other GlideRecord objects

Parameters

Name	Type	Required	Description
enable	boolean	Yes	Whether to enable Business Rule execution for this GlideRecord instance. Pass false to suppress Business Rules, true to enable them. Defaults to true when not explicitly set.

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 bulk update without Business Rulesbasic

// Bulk update incident priorities without triggering notifications
var gr = new GlideRecord('incident');
gr.addQuery('state', 'IN', '1,2,3'); // New, In Progress, On Hold
gr.addQuery('priority', '4'); // Low priority
gr.query();

while (gr.next()) {
    // Suppress Business Rules to avoid notification spam
    gr.setWorkflow(false);
    gr.priority = 3; // Medium priority
    gr.update();
}

gs.info('Updated ' + gr.getRowCount() + ' incidents without notifications');

This example shows the most common use case: bulk updates where you want to suppress Business Rules that would normally send notifications or trigger other side effects.

Data migration with selective workflow controlintermediate

// Migrate user data while controlling Business Rule execution
var sourceGr = new GlideRecord('sys_user');
sourceGr.addQuery('department', 'OLD_DEPT_001');
sourceGr.query();

while (sourceGr.next()) {
    var targetGr = new GlideRecord('sys_user');
    targetGr.get(sourceGr.sys_id);
    
    // Disable workflow for the update to avoid onboarding emails
    targetGr.setWorkflow(false);
    targetGr.department = 'NEW_DEPT_001';
    targetGr.location = 'new_office_location';
    targetGr.update();
    
    // Create audit record WITH Business Rules enabled
    var auditGr = new GlideRecord('u_user_migration_log');
    auditGr.setWorkflow(true); // Explicitly enable for audit trail
    auditGr.user = sourceGr.sys_id;
    auditGr.migration_date = new GlideDateTime();
    auditGr.insert();
}

This pattern shows how to selectively control workflow execution within the same script, disabling it for the main operation but enabling it for audit logging.

The classic mistake - workflow setting after database operationadvanced

// WRONG: Setting workflow after the database operation
var gr = new GlideRecord('incident');
if (gr.get('INC0000123')) {
    gr.short_description = 'Updated description';
    gr.update(); // Business Rules fire here!
    gr.setWorkflow(false); // Too late - has no effect
}

// CORRECT: Set workflow before database operations
var gr2 = new GlideRecord('incident');
if (gr2.get('INC0000123')) {
    gr2.setWorkflow(false); // Must be before update()
    gr2.short_description = 'Updated description';
    gr2.update(); // Business Rules suppressed
}

The workflow setting only affects subsequent database operations, not operations that have already executed. Always call setWorkflow() before insert(), update(), or deleteRecord().

Gotchas

The workflow setting only affects the specific GlideRecord instance - creating a new GlideRecord object resets workflow to enabled by default.

You must call setWorkflow() before the database operation (insert, update, deleteRecord) - calling it afterward has no effect on that operation.

Business Rules are completely bypassed, but ACLs still execute and can prevent the database operation from succeeding.

Notifications triggered directly by Business Rules won't fire, but notifications configured through other mechanisms (like events) may still execute.

The workflow setting persists for the lifetime of the GlideRecord object - subsequent operations on the same object will continue to have workflows disabled until explicitly re-enabled.

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