Knowledge Valid to field change -URGENT

[PraneetaV]

Hi everyone,

I’m working on a requirement to build a dashboard that shows a monthly bifurcation of Knowledge Article updates:

1. Articles where content was modified

2. Articles where only the Valid To date was changed (no other field updates)

What I’ve done so far:

• Created a Metric Definition on the kb_knowledge table for the valid_to field

• Enabled Audit on the valid_to field

• Implemented a Business Rule to detect changes to valid_to

Issue:

• I do see audit records being generated in sys_audit

• However, the Metric Definition is not capturing any data in metric_instance

• Also, I only see options like Field value duration and Script calculation in Metric Type (no “Field value change” option)

My questions:

1. Is it expected that Metric Definitions won’t capture field changes in this case?

2. Is there a way to track field change counts using Metrics without “Field value change” type?

3. For my use case (distinguishing “only valid_to changed” vs “content modified”), is using a Business Rule + custom table the recommended approach?

Any guidance or best practices would be really helpful.

Thanks in advance!

[GlideFather]

Hi @PraneetaV,

could you possibly explain what do you mean "Implemented a Business Rule to detect changes to valid_to"?

Share what you tried to review it, saying "implemented business rule" is not enough.

Also, can you explain why is it important to know that a valid_to has changed?

Just an idea, maybe it can be done differently, business rule triggered when valid_to changes, it will fire an event and this event will be used for next processing. But i don't see the purpose of it to give oyu better suggestions, what is the benefit or business justification for that?

[AhsanM]

Great question! To answer your points directly:

1. Yes, it's expected that Metric Definitions won't capture field changes the way you're hoping. The "Field value change" metric type was deprecated in older versions and isn't available in recent releases, so what you're seeing is normal.

2. Metrics aren't really designed for counting field change events. They're better suited for measuring durations or calculated values. Using sys_audit to count changes is the right instinct, but Metric Definitions won't bridge that gap cleanly.

3. Yes, Business Rule + custom table is absolutely the recommended approach for your use case. Here's how I'd structure it:

- Create a custom table (e.g. u_kb_change_log) with fields for article, change_type ("content_modified" or "valid_to_only"), and month
- In your Business Rule, check which fields actually changed using current.changes()
- If only valid_to changed, log it as "valid_to_only". If any other fields changed (like text, short_description), log as "content_modified"
- Build your dashboard report off this custom table with a monthly grouping

The key condition to distinguish them:
```javascript
if (current.valid_to.changes() && !current.text.changes() && !current.short_description.changes()) {
// only valid_to changed
}
```

This gives you clean, reportable data without relying on sys_audit queries which can get slow at scale.

If you want to validate your Business Rule logic before deploying, there is a free tool called NowFixer specifically for debugging ServiceNow scripts. You can get the link to it from my ServiceNow profile bio. It might save you a few iterations. Good luck with the dashboard!