What It Does
The deleteMultiple() method executes a single SQL DELETE statement that removes all records matching the current query conditions. Unlike deleteRecord(), which processes one record at a time, this method operates directly at the database level without loading individual records into memory.
ServiceNow translates your query conditions into a WHERE clause and executes the deletion as a single database transaction. The platform skips the entire record lifecycle - no before/after Business Rules, no notifications, no workflow activities, and no approval processing. ACL checks still apply during the initial query construction, but not during the actual deletion.
This method returns void regardless of success or failure. You cannot determine how many records were deleted or if any errors occurred.
The method respects domain separation and will only delete records visible to the current domain context. However, it ignores reference field dependencies and will attempt to delete records even if they're referenced by other tables, potentially creating orphaned references. The database foreign key constraints may prevent the deletion in such cases, but the method provides no feedback about constraint violations.
Unlike deleteRecord() which requires iterating through a query result, or setWorkflow(false) which only disables workflow activities, deleteMultiple() bypasses the entire GlideRecord processing framework. This makes it extremely fast for bulk operations but removes all safety mechanisms.
When to Use This
Use deleteMultiple() for bulk cleanup operations where you need maximum performance and explicitly want to bypass Business Rules. Common scenarios include scheduled jobs that purge old temporary records, data migration cleanup, or removing test data where the associated processing would be counterproductive. This is particularly valuable when deleting thousands of records where individual deleteRecord() calls would time out.
Never use this method when you need Business Rules to fire, notifications to be sent, or audit trails to be maintained. Use deleteRecord() within a while loop instead when the business logic associated with individual record deletion is important. Avoid this method entirely on tables with complex reference relationships unless you've verified that orphaned references won't break functionality.
Return Value
This method returns void in all cases. You cannot determine success, failure, or the number of affected records from the return value. The method completes silently whether it deletes zero records, thousands of records, or encounters database errors that prevent deletion.
To verify the operation's effect, query the table before and after the deletion or implement your own logging mechanism. Database constraint violations or permission errors may prevent deletion without any indication to your script, making pre-deletion validation essential for mission-critical operations.
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
- No Business Rules fire (before, after, async, or display)
- No notifications are sent regardless of notification rules on the table
- Audit records are still created if auditing is enabled on the table
- Executes as a single database transaction, making it significantly faster than iterative deletion
- ACL read permissions are checked when building the query, but delete ACLs are bypassed during execution
- Domain separation is respected - only deletes records visible to the current domain
- Reference field constraints may silently prevent deletion without error feedback
