For reporting on knowledge searches - how do I only report on actual searches of the knowledge base

[chrisperry]

When I go look at the logs for knowledge searches, it is showing all knowledge searches - including automatic knowledge searches that are initiated when a user is typing the short description into an incident ticket.   How can I distinguish between knowledge searches actually made by a user vs. knowledge searches that were automatically sent when a user was entering the short description of an incident ticket?   Thanks, Chris perry

[LaurentChicoine · Accepted solution]

Hi Christopher,

I had the same issue as you as the contextual search was making the search logs completely useless with partial search and searches with the incident name used by our support teams.

Also, something interesting to be noted is that the new service portal in helsinki does not log the search made in the KB. Which means we will have to customize the widget to add the search log.

I chose to remove the contextual search (blacklist), a whitelist approach could also had been used. I only took the beginning of the URI being used for search so it might block some other macro searchs but personnaly what I was most interested into was search in $knowledge.do which is not using this URI.

Business rule: Remove KB contextual search logs

Table: Knowledge Searches [ts_query_kb]

Advanced: true

When: Before

Insert: true

Script (put inside the before function or the executeRule function):

var blockedURIs = ['xmlhttp.do?cxs_macro_names'];
try{
       var URI = gs.action.getGlideURI().toString();
       for (var i = 0; i < blockedURIs.length; i++){
               if(URI.startsWith(blockedURIs[i])){
                       current.setAbortAction('true');
               }
       }
}
catch(e){
       //catch error in situation where the GlideURI is not defined such as inside the service portal
}

I chose to simply abort action which does not insert the search in the search log but you could choose to populate a custom field to flag this search as a contextual search.

WARNING: This script relies on a function/object that is not officialy documented by ServiceNow ("gs.action.getGlideURI()"). ServiceNow could chose to remove or modify this function/object without any warning and that could break this script that is proposed.

[kriss]

Do you know if this impacts the Relevant Document [cxs_relevant_doc} table results? We are looking at it as a means to determine if knowledge deterred an incident.

[Michael QCKM]

Nearly certain it does impact relevant document.  We too turned off the Contextual search as it wasn't implemented well OOB in Jakarta/Kingston... since then we've lost all logging in that cxs_relevant_doc table = sad.  Need to revisit when able.

[LaurentChicoine]

I did try it and the business rule I proposed have no impact on the Relevent Document, it only prevents insert on the Knowledge Searches table. If you fear having any other functionality blocked by the business rule I proposed, you can simply add a custom true/false field on Knowledge Searches and inside the if condition you put this field to true instead of setting abort action. You could then filter the search logs based on that field.