Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

How can we provide read-only access for few specific fields of "sys_audit" table to any user?

SakshiJadhav
Tera Contributor

Currently, users either have full access or no access to the "sys_audit" table, with no way to restrict visibility to specific fields. This issue requires configuring field-level read-only ACLs on select fields of the "sys_audit" table so that designated users can view only those specific fields without being able to edit, create, or delete records, and without gaining access to other sensitive fields in the table.

3 REPLIES 3

yashkamde
Giga Sage

Hello @SakshiJadhav ,

 

Did you tried adding field level ACL?

OR Create a new ACL per field :

  • Type: record
  • Operation: read
  • Table: sys_audit
  • Field: sys_audit.fieldname

Then Add the role that should see that field..

Also Refer this might help :

Audit Records: add READ rights to another users 

 

If my response helped mark as helpful and accept the solution.

vaishali231
Kilo Sage

Hey @SakshiJadhav 

You can achieve this using field-level Read ACLs on the sys_audit table. Grant the designated role read access only to the required fields, while keeping Create, Write, and Delete access restricted.

Make sure the table-level Read ACL is also configured appropriately, as field-level ACLs work in addition to table-level access. Avoid relying only on UI policies or field visibility, since those don't provide server-side security.

You can configure:

vaishali231_0-1789457743777.png

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb






musislam
Kilo Sage

Hi @SakshiJadhav,

 

A field-level ACL alone won't get you there. The platform checks the table-level read ACL first, and OOB sys_audit read is limited to admin / audit_viewer (the granular role that ships from Zurich onwards). So non-admins never get in, and anyone who does passes straight through to every field. You need a fence in the middle. Four pieces (all need security_admin elevated):

1. Role - create u_audit_restricted_viewer. Keep it separate from audit_viewer, which is full read.

2. Table read ACL - Table: sys_audit, Operation: read, Role: u_audit_restricted_viewer. Don't add write/create/delete - OOB already locks those to audit_admin, so the role is read-only by default.

3. Wildcard fence - Name: sys_audit.*, Operation: read, Advanced ticked, Script:

answer = !gs.hasRole('u_audit_restricted_viewer') || gs.hasRole('audit_viewer') || gs.hasRole('audit_admin');

This hides every field from the restricted role and leaves all existing users exactly as they are.

4. Field read ACLs - one per field you want visible (I used sys_audit.tablename, sys_audit.documentkey, sys_audit.fieldname, sys_audit.user, sys_audit.sys_created_on), Role: u_audit_restricted_viewer. The specific field ACL wins over sys_audit.*, so only these show and oldvalue / newvalue / reason stay hidden.

Tested on an Australia PDI by impersonating a user holding only that role: the Sys Audit list opens, allowed columns render, Old/New value columns are blank, the form is read-only with no Update button, and canWrite/canCreate/canDelete all return false.

Bonus: if they should only see audits for certain tables, put a condition on the table read ACL (e.g. Table name = incident). Recent releases auto-derive a query ACL from it, so the list is pre-filtered instead of showing "rows removed by security constraints".

Update set attached - import, assign the role to a test user, impersonate and check.

 

Update Set - Community - sys_audit field-level read-only access 

 

If that works for you, mind marking it as the recommended solution? Helps me support these better for the community.

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌  if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community

 

Macki | Deloitte AU | Engineer Lead