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

[SakshiJ]

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.

[kmohammed]

Hi SakshiJ,

This is doable with field-level ACLs, but there is one step most people miss: the wildcard field ACL. Field ACL evaluation uses the most specific matching ACL - a field-specific ACL for the field being read, otherwise the wildcard (table.*) ACL, and only if neither exists does the table-level ACL decide. So if you grant table read plus ACLs for a few fields, every other field still falls back to table read and becomes visible. The configuration is:

1. Create a dedicated role (for example audit_limited_reader) and assign it only to the designated users/groups. Do not reuse a broadly-held role.

2. Table-level read ACL: sys_security_acl with Type = record, Operation = read, Name = sys_audit (no field suffix), requiring that role. This gives row access only - row access alone is not enough for any field, and you create no create/write/delete ACLs at all, which keeps it read-only.

3. Wildcard deny: create a read ACL named sys_audit.* whose script simply sets answer = false (advanced view). Because a non-admin user will never pass it, every field that has no specific ACL of its own is now hidden for these users - this is the step that closes the fallback described above.

4. One read ACL per allowed field: sys_audit.fieldname, sys_audit.tablename, sys_audit.documentkey (record), sys_audit.oldvalue, sys_audit.newvalue, sys_audit.user, sys_audit.sys_created_on - each Operation = read, requiring the role from step 1. Add or remove fields here to tune exactly what they see.

Test as one of the designated users (impersonate - ACL results differ completely for admins, who will still see everything): open the sys_audit list, a single record, and a Table API query for the same record. Expected result: allowed columns show values, all other columns come back empty / are omitted, and the New/Edit/Delete actions are unavailable because no write-path ACLs exist.

Two cautions specific to sys_audit:

- It is one of the largest tables in the instance. Unfiltered list queries from non-admin users will be slow; scope the exposure with ACL conditions (for example limiting tablename to the tables they actually need history for) or give them a report/History view instead of raw table access.

- If the real requirement is only "who changed what on records of table X", the lighter alternative is the record History (sys_history / History related list), which is driven by access to the record itself and needs no sys_audit ACLs at all. Use the ACL approach when they genuinely need to query audit data across records.

Regards,

Karimuddin