Users with delete permissions cannot delete on a custom table

[Tony V]

I built a couple custom tables and granted delete permissions to a particular role,but users wiht that role still cannot delete records.

The custom tables are in the Global scope and are not extended from any other table.

When I created them the system automatically creates roles for each

   I did not create any UI or Data policies

   I did not create any UI actions - I am relying on the default global actions

I then created another role and added both of the table roles as child roles

I created read, write, create, and delete ACLs and added the parent role

I added the 'parent' role to a group

When I impersonate a user in the group they can read,  write, and create, but cannot delete.

In the list view the Delete option is grayed out on the context menu and when viewing in form view the Delete UI action is not visible.

When I, as an admin, go to the tables I can delete - that is Delete is not grayed out in the list view and I see the Delete UI action when in form view. So this is clearly a permission issue.

What did I overlook?

[KrishnaMohan]

HI @Tony V 

Have to try/debug with Access Analyzer?

Access Analyzer is a lifesaver for this because it removes the "guesswork" of impersonating and clicking around. Since you are in a Global scope with custom tables, it will quickly pinpoint if the issue is a specific ACL, a missing role, or a table-level constraint.

Here is how to run the analysis to find your "missing" Delete permission:

1. Open Access Analyzer

In the Filter Navigator, go to System Security > Access Analyzer > Evaluate Access.

2. Configure the Test

Fill out the analyzer form as follows:

• Analyze by: Select User or Role or Group.

• User: Select the specific user you were impersonating (the one in the group with the parent role).

• Rule type: Select Table (Record).

• Table: Search for your custom table name.

• Record: (Optional) If you have specific records with different conditions, select one. Otherwise, leave it blank to test general table access.

Click Analyze Permissions.

3 . Read the Results

The results will appear in a clean table showing Create, Read, Write, and Delete.

• Look at the Delete row. It will likely show a red "Blocked" or "Denied" status.

• Click the "Blocked" link in that row. This is the "magic" step—it will open a side panel or list showing exactly which ACLs were evaluated.

References: https://www.servicenow.com/community/platform-privacy-security-blog/vancouver-release-customers-gain...

If this helped to answer your query, please mark it helpful & accept the solution.
Thanks!
Krishnamohan

[Tony V]

Thank you. I had forgotten about the analyzer. Unfortunately it returns a Pass on the Delete operation. So it did not provide any insight. Any other thoughts?

Access Results

Operation	Overall Access	ACL	Access handler	Data filtration
delete	Passed	Passed	Skipped	Skipped

Debug Logs

#

Name

Decision type

Applies to condition

Empty

ACL Applies to

Status

Required ACL Roles

Role

Security Attribute

Condition

Script

Customized

1

[table]

Allow access

TRUE

FALSE

Table

Passed

[role]

Passed

Skipped

Skipped

Skipped

Yes

[Tony V]

The customer reported that may have some kind of controls around the Delete function. That may be come from a rpevious vendor. They do not know how it was implemented and I could not find it myself. If we ever track irt down I will update this thread.