Can we inactivate all the OOB 'Delete' Acls for some specific tabels which includes OOB tables also?

[YashSha9462]

Hello,

I have a requirement where we are restricting the 'delete' action for all the users in our instance and on all the tables which includes custom as well as OOB tables (eg. sys_attachment, sys_user, sys_user_has_role, sys_script, sys_user_role, incident, problem...etc.).

As of now we are thinking of a solution to disable all the delete ACLs on these table and to create new ACL for these tables and go ahead with this solution. 

But there could be some repercussions with this approach as we will be disabling all the OOB delete Acls for these crucial tables. So I wanted to check if we can go ahead with this solution?

Also, if not this then what could be the best approach?

Thanks in advance.

[Naveen20]

Can you deactivate - yes, but you shouldn't. Deactivating OOB ACLs on core system tables is risky because platform processes, workflows, and system operations rely on those ACLs internally. You can break background cleanup jobs, cascade deletes, update set operations, and other system behaviors that legitimately need delete access.

Better approaches, in order of preference:

1. Create higher-priority "deny" ACLs (Recommended). Instead of disabling OOB ACLs, create new Delete ACLs on each target table that explicitly deny access. Since ServiceNow evaluates ACLs from most-specific to least-specific, a table-level delete ACL with a restrictive script or condition will take precedence. In the ACL, grant delete only to a very specific role (e.g., a custom x_delete_admin role), so everyone else is denied. System operations using setWorkflow(false) or running as system will still bypass ACLs as expected.

2. Use a single "catch-all" Delete ACL on * (wildcard). Create a Delete ACL on table * that requires a custom elevated role. This acts as a global default — if no more-specific ACL grants delete, this one controls it. This is cleaner than touching dozens of individual tables, but test thoroughly since it affects every table.

3. Use Before-query Business Rules as a safety net. For the most critical tables, add a before-query business rule that calls current.setAbortAction(true) on delete operations for unauthorized users. This provides a second layer of protection independent of ACLs.

Key things to keep in mind:

• Always use gs.hasRole() checks rather than blanket denials so system admins or a dedicated role can still delete when legitimately needed.
• Background system processes (like attachment cleanup, log rotation, temp table purging) perform deletes internally — blocking those can cause table bloat and performance degradation.
• Test in a sub-production instance extensively, especially around update sets, CMDB reconciliation, and import set cleanup.
• Document every ACL you create so future admins understand the restriction layer.

The "create restrictive ACLs that layer on top" approach is far safer than deactivating OOB ones, and it's the pattern ServiceNow themselves recommend for tightening security.

[Ankur Bawiskar]

@YashSha9462 

yes if your customer wants to control Delete then better to disable the OOTB ACLs and create new one

Just 1 impact -> during upgrade the OOTB ACLs will be skipped, which you can anyhow review and add new enhancement if any to the new version in your newly created ACL

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tanushree Maiti]

Hi @YashSha9462 

It’s generally not recommended to modify out-of-the-box (OOB) ACLs.

However, if there’s no alternative to meet the requirement, deactivating it can be considered—provided you ensure it doesn’t negatively impact other users.