The Case of the Missing Audit Log: Debugging Unexpected Field Updates in ServiceNow IRM

 

🧩 Introduction

Audit history is one of ServiceNow's most powerful features — especially in compliance-heavy environments like Integrated Risk Management (IRM). But what happens when a field update appears in audit logs… and yet, the actual value in the record is something else entirely?

In this article, we dive into a real-world debugging experience where the "Valid To" field on a Policy Exception record showed unexpected behavior:

• Audit history said one thing,

• But the actual value in the record said another,

• And there was no log of the second change.

Let’s unpack the mystery and walk through how to debug and fix it.

---

🎯 The Scenario

Imagine this:

• A workflow sets the Valid To date based on an extension request.

• The audit log correctly records the update:

  Valid To changed from 2024-06-01 to 2025-06-01

• But when the user opens the record… the value is 2025-07-01!

• And there’s no second audit trail showing that change.

Spooky? Not really. Here's why it happens — and how to fix it.

---

🛠️ Common Root Causes

✅ 1. Audit Suppressed in Second Update

Most often, a second script or flow step updates the field using code like:

gr.setWorkflow(false);
gr.autoSysFields(false);
gr.setValue('valid_to', '2025-07-01');
gr.update();

This silently updates the record without triggering workflows or audit history. It’s commonly used (but risky) in scripted fixes or back-end updates.

---

✅ 2. Parallel Workflow Paths or Subflows

In Flow Designer, multiple paths may be active:

• One branch sets the expected value

• Another runs later and overwrites it silently

These steps can conflict if timing and conditions aren’t carefully managed.

---

✅ 3. Custom Business Rules or Fix Scripts

An after update Business Rule might be listening for something like extension_granted = true, and then adjusting valid_to automatically — possibly without your knowledge.

---

🧪 How to Diagnose the Issue

🔍 Step 1: Confirm Audit Settings

• Go to System Definition > Dictionary

• Find the Valid To field

• Make sure Audit = true

🔍 Step 2: Add a Temporary Debug Business Rule

Create a rule on sn_compliance_policy_exception:

(function executeRule(current, previous) {
   if (current.valid_to != previous.valid_to) {
      gs.info("[Audit Debug] Valid To changed: " + previous.valid_to + " → " + current.valid_to);
   }
})(current, previous);

This will catch silent or unexpected changes in the logs.

🔍 Step 3: Review sys_update_xml

• Navigate to sys_update_xml.list

• Filter by table = sn_compliance_policy_exception

• Look for recent script or Flow-based changes

🔍 Step 4: Trace Flow Designer Executions

Use Flow Execution records to:

• Trace exactly which flow or subflow ran

• Identify timing conflicts or overwrite issues

---

✅ How to Fix It

Issue	Fix
Script updates without audit	Avoid using setWorkflow(false) or use logging manually
Subflow overwriting value	Add guardrails like conditions or mutually exclusive paths
Business Rule silently modifying value	Log the source and review all after-update rules

📊 Bonus: Set Up Audit Logging with Explanation

Want to catch even stealthier changes? Add a log field (u_valid_to_reason) that stores why a value was changed — manually, via workflow, or script.

---

🧭 Conclusion

Unexpected field values with mismatched audit history are a red flag — especially in IRM and compliance workflows. Fortunately, with the right debugging steps, you can identify silent updates and take control over field integrity.

Audit trails are only as good as the rules that protect them — so use script discipline, flow clarity, and logging best practices to make sure no change goes untracked.