Speaking about the process, yes the last statement makes sense. But sometimes the attached KB Article can be misleading and a new KB can be attached as a hyperlink in Notes section or attached 2 complimentary KBs which is not possible in 1 field.
Yet, if we focus on the goal - "Create more relevant KB Articles, Assess access of public/snc_internal role based KBs that helps users":
1. Maybe the Report should be only based on field under Related Records (since reporting on work notes or journals is not so easy) - yes like mentioned this is not a complete view.
2. To achieve the other half, you can configure a Business Rule (async) where once the KB related notes are found either in Worknotes or Additional comments then the system automatically populates the field say "KB Article" (but if already a value exists, then we can skip)
Here is a sample code:
(function executeRule(current, previous /*null when async*/) {
var kbRegex = /KB\d+/; // Regular expression format 'KB' followed by digits
var commentsOrWorknotes = current.comments.getJournalEntry(1) || current.work_notes.getJournalEntry(1);
if (commentsOrWorknotes) {
var kbMatch = commentsOrWorknotes.match(kbRegex);
if (kbMatch && kbMatch.length > 0) {
var kbNumber = kbMatch[0]; // Extract KB number like 'KB0000123'
var kb= new GlideRecord('kb_knowledge');
if (kb.get('number', kbNumber)) {
current.u_kb_article = kb.sys_id;
}
}
}
})(current, previous);
But the challenge here is, it works only for future records but not for the past. I understand this can be of help in the later stages but not immediately yet you can give it a start to define a system specific process for handling this issue.
Regards, Akash
If my response proves useful, please mark it "Accept as Solution" and "Helpful". This action benefits both the community and me.
