I
f you’ve worked with ServiceNow much at all, you’re probably familiar with the capability provided to search knowledge from the incident form, and then attach the knowledge article back to the originating incident. This behavior is extremely useful and can be customized if needed. One complaint I’ve heard about this behavior before is that it posts back the entire contents of the knowledge article into the ‘Comments’ field on the incident. The advantage to this setup is that the solution then gets sent directly out to the end user in their email, but it also comes with a disadvantage since the user never actually has to interact with the Knowledge Base or even know that they could have found their solution there.
One way to better promote knowledge use among your end user community (while still providing useful solutions) is to customize this default attach behavior to send a link to the knowledge article rather than the full text in the Incident ‘Comments’ field. In this article, I’ll show you how that can be done!
You’ll only need to change a single record to make this modification. Navigate to ‘System Definition -> Script Includes’ in your left nav and open the ‘KnowledgeAjax’ script include. Look for the following chunk of code (which is responsible for returning the full KB article text to the incident form) and comment it out…
if (gs.getProperty("glide.ui.security.allow_codetag", "true") != "true")
s += article.short_description;
else {
var displayValue = new KnowledgeHelp(article).findDisplayValue();
s += "[code]" + displayValue + "[/code]";
}
Then, directly above or below that code, paste the following code and update the record…
var s = "Knowledge article " + article.number + ": " + article.short_description + "\n";
if (gs.getProperty("glide.ui.security.allow_codetag", "true") != "true")
s += gs.getProperty('glide.servlet.uri') + "kb_view.do?sysparm_article=" + article.number;
else {
s = "Knowledge article ";
s += '[code]<a href="' + gs.getProperty('glide.servlet.uri') + 'nav_to.do?uri=kb_view.do?sysparm_article=' + article.number + '" style="color:blue">' + article.number + '</a>[/code]' + ": " + article.short_description + "\n";
}
Fuji instances introduce a dynamic search functionality that allows you to attach articles from a dynamic search component underneath the ‘Short Description’ field. For some reason, ServiceNow has changed the location of the attach code for the new components (even though the code is largely the same) to a script include named ‘cxs_Knowledge’. Unfortunately, they’ve also put a read-only protection policy on the script include so you can’t edit it! In order to get this to work in a Fuji instance, you’ll need to override the ‘cxs_Knowledge’ script include by creating an exact duplicate copy…same name, same code, etc. Then, follow the procedure described above to replace the code within your new ‘cxs_Knowledge’ script include.
If you’ve updated the record correctly, you should be able to see the results by testing the attach knowledge functionality from the incident screen.
Great post. I made minor change when using the code and added nav_to.do? in the url:
The reason for that is: the contact for the incident received an email with the comment. When click on the link of the KB article in the email, I was redirect to the homepage. Adding “nav_to.do?” just after the uri allow the KB article to be displayed properly. We are using Lotus Notes, not sure if this is limited to the Lotus Notes.
Good catch! That will happen any time you hit that link without being authenticated. What’s interesting is that’s the standard permalink structure from ServiceNow KB articles. I like your solution better because it will work even if authentication is required. I’ve updated the solution above to include ‘nav_to.do’.
HI
I got this to work and its great 🙂
We input this into our comments box which sends an email to the customer
unfortunately its sending the full hyperlink text (see below)
Any ideas on how to fix this?
Dear Customer, Please reference this article for your solution: [code]KB0010953[/code]: How to create a Knowledge Base article
What happens when you use the original ServiceNow code? Does the link render correctly in the activity section on the incident? In my instance, the link renders correctly, and the ‘[code]’ tags get stripped out when the email hits the ServiceNow email log. If you’re seeing issues with the standard setup you’ll probably want to check the ‘glide.ui.security.allow_codetag’ property or contact ServiceNow support.
Hi Mark
When i attach the KB to the incident this is the text i see
You should see that in the comments field right when you attach. What do you see in the activity section after you’ve saved the incident record? If you still see that, then you’ll probably need to reference the property I mentioned above.
Hi Mark
I have that property in the sys_propeties.list.do the value and it is set to our instance.
As I couldn’t get this to work the way i wanted I cut down the code a little and added a message reference so it can support multi-language systems
var z = gs.getMessage('KB SOLUTION_1') + article.number + ": " + article.short_description;
var x = gs.getMessage('KB SOLUTION_2');
var s = z + "\n";
s += gs.getProperty('glide.servlet.uri') + "kb_view.do?sysparm_article=" + article.number + "\n" + x;
The finished product comes out like this:
Dear customer, Thank you for your request! We think we have a solution for you located here:
KB0011007: Update Server Warranty Information in Service-Now
https://instance name /kb_view.do?sysparm_article=KB0011007
If the solution provided does not help you to resolve your issue, please reopen the call using the red button.
I’m going to keep working on this if i find a solution i’ll update the article thanks for the Help 🙂
Is there a way to have the attached knowledge refresh upon attachment
No simple way currently. It’s technically possible, but you would really have to reconstruct the entire ‘attached_knowledge’ UI macro and come up with some client script hacks to make it work.
First of all thank you for the quick reply! And well that at least gives me a place to start, I’ll write back if I figure anything out.
This worked for updating the incident ticket with the link, but when I receive the email, there is no link.
Check your email logs to make sure the link is in the email log as it is sent. In my testing on the ServiceNow demo instance, it’s there in the email log. I’m not sure what the difference might be in your instance.
No, it’s not a link in the email log either.
If you attach knowledge the regular way does it render your html and include that in an email? This solution doesn’t really change the way any of that works. It’s simply entering different HTML in the comments field. It sounds like something is messing with the HTML of your emails and you’ll probably need to work with ServiceNow support on that.
Yes, the knowledge article shows up the regular way and if there are links in the knowledge article, they show up correctly also.
I opened a ticket with ServiceNow about this and they said it is a known bug (links created via [code] tags are stripped from email notifications) to be fixed in the Dublin release.
I have a question that someone may be able to assist with:
We have set up Index KBs for our applications. Then we have article KBs that cover specific problems with the applictions. The Index KB has links to all the articles associated with that application. If someone searches the KB from an Incident and clicks directly on the article or the Index, it gives us the option to “Attach to Incident.” However, if you open the Index and then click the link for the associated article, the article will open, but the “Attach to Incident” option is gone. Anyone have any suggestions on how we can keep that functionality after clicking and opening the linked KBs?
Working in Fuji. I’ve done the above stepson KnowledgeAjax. It does nothing to change the way it works. I’ve disabled KBMyKnowledge, KBMyKnowledgeAJAX, KnowledgeAJAX, & KnowledgeVaAjax. I’ve added the proposed script to KBAjax & KBKnowledge. There is no change to how the attach works. In fact, it still works with most script includes disabled.
Any Ideas?
Shawn
Great question. I’m guessing you’re attaching from the new Fuji dynamic search. The new Fuji components introduce a new script include that you need to modify. I just included instructions in the post above explaining how to do this.
Made the required changes in a new copy of cxs_Knowledge. Still getting the HTML code in my comments field.
It’s hard to know without looking at your system specifically. You can log into demo004 today to see what I’ve put out there. Seems to be working there without issue.
I just did the same in my Geneva Dev instance that I did in the Fuji instance. I’m having the same issue in my Geneva Dev instance. Send me an email and I’ll give you access to my Dev instance. We can play around there. I can also do a screen share if that works.
What is the full instance name for demo004? Creds?
I think the SN demo instance should give you the basis of comparison you need. https://demo004.service-now.com/side_door.do. You can log in there with admin/admin. Good luck!
Demo4 doesn’t seem to have any KBs to search.
You may have to try it on another demo instance then. You can use the same url with ‘demo001 – demo023’ and test anything you want there. You’ll have to put the code in on the other instance. I promise it works though!
After trying to get into 6 different instances (being initialized or otherwise unavailable), I was able to validate in demo016. I then went to the QA instance that is still pristine and made the modification. It too worked. Now to figure out why it won’t work in my Geneva Dev instance or the client Dev instance. 🙁
Thanks for all of the help Mark!!! I’ve never had this much trouble getting one of you scripts to work.
Got it. I had created a copy of the protected SI. It was blocking the execution of the editable SI. SNOW deleted the extra and it is now working in the client Geneva Dev instance.
Thanks again Mark!
How do I make this work with the ‘Attach’ button in the Contextual Search?
It doesn’t seem to work if I have the Contextual Search added to my form, it doesn’t work