GlideRecord.deleteRecord()

What It Does

The deleteRecord() method permanently removes the current record from the database. The GlideRecord must be positioned on a valid record (using get() or retrieved through a query) before calling this method. Unlike deleteMultiple(), this method operates only on the single current record.

Internally, ServiceNow executes the delete operation through several phases. Before deletion, all before delete business rules fire, giving them opportunity to cancel the operation by calling current.setAbortAction(true). The platform then removes the record from the table and fires after delete business rules. This entire process respects ACL configurations, meaning the operation may fail without error if the executing user lacks delete permissions.

The method returns true when the deletion succeeds, false when it fails. Failure can occur due to insufficient ACL permissions, business rule abortion, database constraints (like foreign key relationships), or attempting to delete a record that doesn't exist. The method will not throw exceptions for these failure conditions.

Edge cases include attempting to delete records with dependent child records (which may fail due to referential integrity), deleting records in extended tables (which removes the record from both parent and child tables), and deleting records that have been modified by another user since retrieval. The method handles these gracefully by returning false rather than throwing exceptions.

This method contrasts with deleteMultiple() which operates on all records matching the current query, and setWorkflow(false) which can be called beforehand to skip business rule execution. Unlike client-side operations, deleteRecord() immediately commits the change to the database.

When to Use This

Use deleteRecord() when you need to remove a specific record that you've already retrieved and want business rules to execute normally. This is the standard approach for single record deletion in business rules, script includes, and scheduled jobs. The method is particularly appropriate when you need the return value to confirm successful deletion or when working with records that have complex deletion logic implemented in business rules.

Choose deleteMultiple() instead when removing multiple records based on query conditions, as it's more efficient for bulk operations. Use direct database operations or the REST API when working with large datasets where business rule overhead becomes a performance concern. Avoid deleteRecord() in loops over large result sets, as each call triggers the full business rule stack.

Common misuse includes calling the method without first checking if the GlideRecord is positioned on a valid record, ignoring the return value in scenarios where failure matters, and using it for data archival purposes where setting an inactive flag would be more appropriate. The method should also not be used in before business rules on the same table, as this can create unpredictable execution order issues.

Return Value

The method returns a boolean value: true indicates successful deletion, while false indicates failure. The boolean is immediately available after the method call completes, making it suitable for conditional logic that depends on deletion success. Unlike some GlideRecord methods, this return value is reliable and always represents the actual outcome of the delete operation.

Failure scenarios that return false include ACL permission denial, business rule abortion via setAbortAction(true), database constraint violations, and attempts to delete non-existent records. The return value should be checked in production code where deletion failure needs to be handled, such as logging errors or notifying users. Simply checking if (gr.deleteRecord()) { /* success */ } else { /* handle failure */ } provides robust error handling.

Platform Behavior & Side Effects

• Triggers all before delete and after delete business rules in sequence, including inherited business rules from parent tables
• Enforces delete ACL permissions and returns false if user lacks delete rights, without throwing exceptions or logging security violations
• Creates audit trail entries when auditing is enabled on the table, recording the deletion with timestamp and user information
• Immediately commits the deletion to the database without requiring additional transaction management or update() calls
• Performance scales linearly with business rule complexity, making it unsuitable for high-volume batch deletions without workflow disabling
• Removes records from both parent and child tables when dealing with table extensions, maintaining referential integrity across the table hierarchy
• May trigger notifications, email scripts, and other platform integrations configured to fire on record deletion events