Business Rules let you block record deletions when certain conditions are met, like preventing closed incidents from being deleted or protecting reference data. You'll build a rule that validates conditions and stops the deletion with a clear error message.
Why you need delete protection
Without delete protection, users can accidentally or intentionally remove records that should be preserved — closed incidents, approved change requests, or reference data that other records depend on. This breaks audit trails, creates data integrity issues, and can cascade into broken references across your instance. Platform admins deal with the fallout when critical records disappear, and there's no built-in undo for deletions in ServiceNow.
How delete Business Rules work
Delete Business Rules fire 'before' the record is removed from the database, giving you a chance to evaluate conditions and abort the operation. You write a condition that identifies which records to protect, then use current.setAbortAction(true) to stop the deletion and gs.addErrorMessage() to tell the user why. This is different from ACL delete restrictions — Business Rules can evaluate complex conditions and provide custom error messages, while ACLs are simpler role-based controls.
Building robust delete protection
Start with a basic condition and error message, then enhance it with specific validation logic for your use case. Production-quality delete rules check for dependent records, provide actionable error messages, and log attempts for security monitoring. You might also add exceptions for admin users or build cascading deletes that clean up related records safely instead of blocking the operation entirely.
Before you start
- •admin role or business_rule_admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Create the Business Rule
Navigate to System Definition > Business Rules and click New. Set the Name to something descriptive like 'Prevent Closed Incident Deletion'. Choose your target Table from the dropdown — this is where the rule will fire. Leave Active checked and set When to 'before'.
Name your rule clearly — you'll thank yourself when debugging delete issues later.
Configure the delete operation
Check only the Delete checkbox under When to run. Leave Insert, Update, and Query unchecked. In the Order field, enter a value like 100 — this controls when your rule runs relative to other delete rules on the same table.
Set your protection condition
In the Condition field, write the logic that identifies which records to protect. For example, 'state=6' to protect closed incidents, or 'sys_created_on<javascript:gs.daysAgoStart(30)' to protect records older than 30 days. This condition determines when the rule fires — only matching records will trigger your delete protection.
Write the abort script
In the Script field, add these two lines: 'current.setAbortAction(true);' and 'gs.addErrorMessage('Cannot delete closed incidents');'. The first line stops the deletion, the second shows your custom error message to the user. Replace the error message with something specific to your use case.
Make error messages actionable — tell users what they should do instead of just what they can't do.
Add role restrictions
In the Role conditions related list, click Edit and add roles that should be able to bypass this rule. For example, add 'admin' if administrators should be able to delete protected records. Leave this empty if the rule should apply to everyone including admins.
Test and activate
Click Submit to save the rule. Test it by finding a record that matches your condition and trying to delete it — you should see your error message and the record should remain. Test with a user who has bypass roles to confirm they can still delete when needed.
Best practices
Write specific conditions that only fire when needed — broad conditions like 'state!=1' can block legitimate deletions unexpectedly.
Always provide clear error messages that tell users why the deletion was blocked and what they should do instead.
Test your rule with different user roles to ensure bypass permissions work correctly — admin users often need to clean up data.
Consider logging delete attempts in a separate table for security monitoring, especially for sensitive record types.
Use Business Rules for complex conditional logic and custom error messages — use ACLs for simple role-based delete restrictions.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue