GlideRecord.updateMultiple()

What It Does

The updateMultiple() method performs a bulk update on all records that match the current GlideRecord query. It applies only the field changes you've made using setValue() calls before invoking the method. Unlike iterating through records with next() and update(), this method executes as a single database operation.

Internally, ServiceNow translates your query and setValue() calls into a SQL UPDATE statement that runs directly against the database. The platform bypasses the normal record processing pipeline entirely—no Business Rules fire, no workflow activities trigger, and ACL checks only happen at the table level, not per record. This direct database approach makes it extremely fast for updating hundreds or thousands of records.

The method returns void—it provides no feedback about how many records were updated or whether the operation succeeded. You must query separately if you need to verify the results. The method also doesn't validate that your query matches any records before executing, so it will silently succeed even when updating zero records.

Edge cases include behavior with invalid queries (the method fails silently) and attempts to update fields that don't exist (also fails silently). The method ignores any orderBy() or setLimit() calls since it updates all matching records regardless of order or limit constraints.

This method relates closely to deleteMultiple() which provides similar bulk operations for deletions. Both methods share the same performance characteristics and bypass the same platform mechanisms. For single-record updates with full Business Rule processing, use update() instead.

When to Use This

Use updateMultiple() when you need to update many records with the same field changes and performance is critical. Scheduled jobs that clean up data, bulk status changes across incidents, or administrative updates to user records are ideal use cases. The method excels when you're updating simple field values and don't need the business logic that Business Rules provide.

Avoid this method when you need Business Rules to fire, when you require audit trails for compliance, or when the updates should trigger notifications or workflow. Use update() in a loop instead if you need the full platform processing, despite the performance cost. Never use updateMultiple() for updates that depend on calculated fields, complex business logic, or cross-table relationships that Business Rules typically handle.

Common misuse includes trying to update records where each record needs different values (impossible with this method), expecting Business Rule logic to execute, or using it in Before Business Rules where the performance gain is minimal but the side effects are dangerous.

Return Value

The method returns void in all cases—successful updates, failed updates, and operations that match zero records all return nothing. This lack of feedback means you cannot determine success or failure from the method call itself. The GlideRecord object remains in its pre-execution state after the call, so you can reuse it for additional operations.

To verify the operation succeeded, perform a separate query to check that the expected field values were applied. When the method encounters an error (such as invalid field names or security violations), it fails silently without throwing exceptions, making error detection impossible without explicit verification.

Platform Behavior & Side Effects

• Business Rules do not execute—no before, after, or async Business Rules fire for any updated records
• ACL checks occur only at the table level during initial query execution, not per record during update
• Audit records are not created—sys_audit table remains unchanged regardless of audit policy settings
• Performance is extremely fast—executes as single SQL statement regardless of record count
• Notifications and events do not trigger—no email notifications or custom events fire
• Database writes occur immediately without transaction rollback protection from Business Rule failures
• Workflow activities do not execute—running workflows remain unaware of field changes