Audit showing as false when using dictionary override?

snow_beginner
Giga Guru

an hour ago

Hi,

I had a requirement to set audit=true on some fields on a table (cmdb_ci_base_rpa_robot), but that table extends from the software table and the fields that needed to be audited were coming from there. 

 

I created dictionary overrides for those fields with audit=true. However, when I look at the list view of those fields in the distionary table and bring audit up, I still see audit as false? Why is that?

 

Also when I change those field or other field values and check in the sys_audit table, then everything seems to have a record there. When I look at the history of the record again, I see audit is done on all of them. Why is that?

 

I have attached a ss of the history record, the encricled fields are supposed to be auited, but all of them are I think. And another ss of the sys_dictionary table showing audit=false on those fields, even though I did create dictionary overrides for them.

Screenshot 2026-06-16 100720.png

 

Screenshot 2026-06-16 100334.png

0 Helpfuls
  • 72 Views
1 REPLY 1

Yogesh11bhatt
Kilo Guru

58m ago

Hi @snow_beginner ,

 

What you're seeing is likely related to how auditing inheritance and dictionary overrides work in ServiceNow.

Why does the Dictionary list still show Audit = false? The records shown in your sys_dictionary list are the base dictionary entries for the parent table. A Dictionary Override is stored separately and does not update the Audit value displayed on the original dictionary record. Because of this, it is possible for the base dictionary entry to show audit = false while an override on the child table enables auditing for that specific field.

To verify this, check the Dictionary Override related list for the field on cmdb_ci_base_rpa_robot or query the override records directly.

Why are other fields appearing in the History/Audit view? Since cmdb_ci_base_rpa_robot is part of the CMDB hierarchy, auditing may be inherited from parent tables or enabled for other fields through existing configurations. Additionally, the History view groups together all audited field changes that occurred during the same update transaction.

I would recommend checking:

  • Whether auditing is enabled on the table or inherited from a parent table.

  • Existing dictionary overrides higher in the table hierarchy.

  • The sys_audit records for the specific fields to confirm exactly which fields are generating audit entries.

If PID and Version are appearing in sys_audit after your changes, that is a good indication that the overrides are functioning as intended, even though the base dictionary records continue to show audit = false.

Hope this helps!

Please mark this answer as Helpful if it resolves your question. 🙂

 

Thanks,

Yogesh Bhatt

0 Helpfuls