Find your people. Pick a challenge. Ship something real. The CreatorCon Hackathon is coming to the Community Pavilion for one epic night. Every skill level, every role welcome. Join us on May 5th and learn more here.

How to report on Knowledge Articles where ONLY the 'Valid To' date was updated?

kateparker7
Giga Contributor

I’m working on a requirement to build a dashboard that shows a monthly breakdown of Knowledge Article updates. Specifically, I need to distinguish between two types of changes:

 

Content Modified: Articles where the actual text or body was updated.

Date Extension Only: Articles where only the Valid To date was changed (and no other fields were touched).

 

I’ve tried using Metric Definitions on the kb_knowledge table for the valid_to field, but I’m having trouble getting it to capture the data correctly in metric_instance. It seems like metrics are better for durations rather than just flagging specific field-level change events.

 

Has anyone done this before? I'm thinking a Business Rule might be the way to go to log these changes to a custom table, but I’d love to know if there's a simpler way to do this using out-of-the-box reporting or audit data without hitting performance issues.

 

Any guidance or script snippets would be greatly appreciated.

2 REPLIES 2

Choudharyma
Tera Contributor

Hi,

 

One approach you could consider is leveraging the sys_audit table, which already captures field-level changes for kb_knowledge records.

You can use it to differentiate your scenarios like this:

  • For Date Extension Only: filter audit records where the field is valid_to, and then group changes by document (article) and timestamp. If only valid_to appears in that update transaction, you can classify it as a date-only extension.

  • For Content Modified: look for audit entries where fields like text, short_description, or description are changed. Any occurrence of these would indicate a content update.

For reporting, you could either:

  • Build a report directly on sys_audit (grouped by month), or

  • Create a scripted logic to group changes per update transaction for more accurate classification.

This way, you can stay OOB and avoid additional Business Rules unless you need very clean, pre-processed reporting.

Hope this helps!

kateparker7
Giga Contributor

Thanks Mate for your contribution.