User is able to insert record on table, even though ACLs should prevent it.

[Nick Peters]

We are going through the process of removing create (insert) access to a number of our tables. Users still need the ability to update (write) records, just not have the ability to create new ones. I have tried - and failed - to implement this on 2 tables now.

Each table only had one row-level create ACL. I deactivated it and created a new row-level create ACL and defined the 'admin' role in the Requires role embedded list. The ACL Execution Plan shows that this is the only active row-level create ACL for this table.

Yet when I impersonate a user, who I have confirmed does not have the 'admin' role, they are still able to insert a record using UI actions.

Any advice on how to proceed or what is causing this behavior? One of the tables in question is the Incident [incident] table.

[Shane J]

As long as they can see the 'New' button, they very likely have create access.  Have you created both create and write ACLs on the tables, or just the create one?  Keep in mind that if you meet the criteria for one of a set of ACLs at the same level, you'll get access instead of being restricted.

[Nick Peters]

They cannot see the New button. There is a custom UI action on the incident table that, when clicked, allows a non-admin user to save/insert a record.

After making the one change to the ACLs that I mentioned in the original post, I witnessed that when viewing a "new record" form, all fields are now read only for the user. I've also enabled Security Rule Debugging, and confirmed that the user does not pass the single create ACL.

I realize that I could simply hide this UI action on insert by including current.isNewRecord() in the condition field. There are other UI actions that are doing this for the other table as well (a custom "intake" table).

[Michael-PHL]

Why don't you just change your UI action to require a role to use it? Or set your conditions?  like the below?

[Nick Peters · Accepted solution]

I've discovered the "issue" and it actually boils down to me not understanding when ACLs are evaluated.

While I do have the ACLs for my respective tables configured correctly, users who did not meet the ACL requirements were still able to insert records. This was because they were doing so through the use of a UI action.

This article explains when ACLs are evaluated:
https://hi.service-now.com/kb_view.do?sysparm_article=KB0677278

As point #2 mentions, server-side JavaScript, which is executed in UI actions to perform a CRUD command, is not subject to ACL evaluation. Hopefully this can help others who encounter this kind of ACL behavior.

For my situation, I'll need to make the ACL adjustment AND hide all UI actions that allow insertion of records.