GlideRecord.setAbortAction()

What It Does

The setAbortAction() method sets a flag on the current GlideRecord that tells ServiceNow whether to proceed with the database operation. When you call setAbortAction(true) in a before Business Rule, ServiceNow cancels the insert, update, or delete operation entirely. The record never touches the database, and processing stops immediately after all before Business Rules complete.

Internally, ServiceNow maintains an abort flag for each database transaction. The setAbortAction() method simply toggles this flag. After all before Business Rules execute, ServiceNow checks the flag. If true, the operation terminates without writing to the database, firing after Business Rules, or triggering notifications. If false or never set, the operation proceeds normally.

The method returns void and never fails. You can call it multiple times within the same Business Rule execution, and the last value wins. Calling setAbortAction(true) then setAbortAction(false) allows the operation to proceed. The platform provides no way to query the current abort state within the same transaction.

Edge cases include calling setAbortAction() from after Business Rules (ignored), Script Includes (only affects GlideRecords created within that context), and async Business Rules (unpredictable timing). The method only affects the specific GlideRecord instance it's called on, not other records being processed in the same transaction.

The method relates closely to addErrorMessage() and getErrorMessages(). Best practice combines setAbortAction(true) with addErrorMessage() to both block the operation and explain why to the user. Without an error message, users see generic "operation failed" feedback.

When to Use This

Use setAbortAction() when you need server-side validation that completely prevents database writes. Common scenarios include enforcing complex business rules that can't be handled by Data Policies, validating against external systems, or implementing approval workflows where certain changes require pre-authorization. This is your go-to method when client-side validation isn't sufficient and the data must not persist.

Avoid setAbortAction() for simple field validation that Data Policies can handle, or when you want to log the attempted change before blocking it. For complex validation that should allow the save but warn the user, use addInfoMessage() instead. For validation that should trigger after the save completes (like sending notifications about the blocked attempt), implement the logic in after Business Rules with separate audit logging.

A common anti-pattern is using setAbortAction() in after Business Rules (where it does nothing) or combining it with current.update() calls in the same before Business Rule. The abort happens after your update() calls complete, so you can create infinite loops or partial data states.

Return Value

The method returns void and cannot fail. There's no return value to check, no exceptions to catch, and no way to determine if the call succeeded. The method simply sets an internal flag and returns immediately. You cannot query whether abort is currently set on a GlideRecord instance.

Since there's no return value, the only way to verify your abort logic works is through testing the actual database operations. Create test records, trigger your Business Rules, and confirm the database remains unchanged. The user interface will typically show error messages (if you added them), but the record form may still display the attempted values even though they never saved.

Platform Behavior & Side Effects

• After Business Rules never fire when setAbortAction(true) is called, preventing notifications, field updates, and other after-save logic from executing
• The database write is completely prevented, meaning no audit trail, no sys_updated_on changes, and no version history entries are created
• ACL evaluations still occur during before Business Rules, but the final ACL check for the write operation is skipped since no write happens
• Performance impact is minimal since the abort happens before expensive database operations, making this faster than allowing invalid saves and rolling them back
• UI actions and client scripts that trigger the save operation receive standard error responses, allowing proper error handling in the browser
• Multiple before Business Rules can call setAbortAction(), with the last call determining the final abort state for that specific record