understanding the sys_user.* acl i created

[ServNowDev]

I disabled the write acl in servicenow for the sys_user.last_name field. 

I created an write sys_user.* acl that requires the user_admin role.

I also disabled the table acl for write sys_user as well.

I gave a test user the user_admin role and when I impersonated the test user they still cannot edit the last name on the user table. Doesnt the sys_user.* allow for write to all fields on the table?

[NavinAgarwal]

Hi @ServNowDev ,

The sys_user.* ACL does not allow write access to all fields on a table. It is designed to allow write access to the entire table, but this does not mean that every field within the table can be edited. Permissions must be explicitly defined for each field within the table to allow write access.

If a user has the sys_user.* ACL but still cannot edit a specific field (in your scenario), it is likely due to the field's ACL settings or the user's role not having the necessary permissions. Please double check if there are any other ACLs written for the sys_user.last_name field which you have not disabled yet.

If you found my response helpful, could you please mark it as ‘Accept as Solution’ and ‘Helpful’? This small action goes a long way in helping other community members find the right answers more easily and supports the community.

[ServNowDev]

there are no other individual acls for the last name field. but your saying .* doesnt give write access to all fields on a table??

[NavinAgarwal]

Hi @ServNowDev ,

I didn't actually meant that usually .* should give access to all fields within that table but in your scenario, it indicates the presence of more specific Access Control Lists (ACLs) that are overriding the general table-level write access. But you are saying there are no field level ACLs.

Some recommended debugging steps:

Have you utilized the ACL Debugger tool to trace the ACL evaluation process? If ACLs are not causing the problem, look for any client scripts as UI Policies and Client Scripts can also make fields read-only on the client-side. Also, you can try creating specific field-level write ACLs to verify if it's granting the access or not.

Hope this helps.

[Ankur Bawiskar]

@ServNowDev 

if you have field level WRITE ACL then it takes priority over Table.*

Check this ACL evaluation

Also debug using access analyzer

[Vancouver Release] Customers gain enhanced access visibility with ServiceNow Access Analyzer 

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