Top 5 Ways to Break (and Fix) Field Auditing in ServiceNow

 

🎯 Introduction

Field auditing in ServiceNow is essential for compliance, troubleshooting, and change tracking — especially in regulated industries or IRM modules. But here’s the kicker: it’s surprisingly easy to break audit logging without even realizing it.

This article covers the top 5 ways audit logging can fail in ServiceNow — and exactly how to fix or prevent them in your environment.

---

✅ 1. Using setWorkflow(false) or autoSysFields(false)

What breaks:
These methods disable system behavior like workflows, business rules, and audit logging.

gr.setWorkflow(false);
gr.autoSysFields(false);
gr.update();  // No audit logged!

Fix:
Only use these methods when you intentionally want to suppress system impact, such as during fix scripts or data loads. Avoid them in production logic that should be tracked.

---

✅ 2. Updating Fields with No Real Change

What breaks:
If you set a field to the same value it already had, ServiceNow does not log an audit entry — even though a setValue() was called.

current.setValue('state', current.state);  // No actual change → no audit

Fix:
Make sure you're changing only when the value truly differs.

if (current.state != 'Closed') {
    current.setValue('state', 'Closed');
}

---

✅ 3. Subflows or Script Includes Rewriting Values Later

What breaks:
A flow or script may initially update a field (which gets audited), but later logic silently overwrites the field again — often with setWorkflow(false) or from another execution path — with no second audit entry.

Fix:

• Trace your flows and subflows for any post-processing that touches audited fields.

• Use temporary business rules to log who’s modifying what and when.

---

✅ 4. Bulk Updates via Import Sets or Data Sources

What breaks:
Import Sets often run with "Run Business Rules" unchecked, which skips audit logging entirely.

Fix:

• Enable Run Business Rules on your Transform Map.

• If you’re doing ETL, build custom logging into the load job.

• For compliance tables (e.g., IRM), avoid audit-suppressed updates wherever possible.

---

✅ 5. Auditing Not Enabled on the Field

What breaks:
The most basic (but common) reason: the field isn’t even marked for audit.

Fix:

• Go to System Definition > Dictionary

• Search for the field and ensure Audit = true

• Re-save if needed. You can even re-enable auditing retroactively for important fields.

---

🧪 Bonus: How to Audit-Proof Your Work

• Use gs.info() logs during development to trace field changes.

• Add After Update business rules to catch unexpected changes.

• Periodically review the sys_audit table to confirm field-level tracking.

• Consider building a custom audit summary dashboard for sensitive tables like sn_compliance_policy_exception or sn_risk_risk.

---

🧭 Conclusion

Field auditing is like insurance — you don’t think about it until you need it. Whether it's for IRM, security, or HR, making sure your changes are properly tracked is a must.

Avoid these 5 common mistakes, and you’ll make your ServiceNow platform more transparent, reliable, and audit-ready.