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…

var s = "Knowledge article " + article.number + ":\n";
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…

//Return a link to the knowledge article instead of the full article text
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 style="color: blue;" href="' + gs.getProperty('glide.servlet.uri') + 'nav_to.do?uri=kb_view.do?sysparm_article=' + article.number + '">' + 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.

The post Send a Knowledge Link when Attaching Knowledge appeared first on ServiceNow Guru.

The first step to making this work is to define your style sheet as shown in the screenshot above. What I’ve done is obviously just an example and you can customize this however you want. Style sheets can be defined under the ‘Content Management’ application in your left navigation toolbar.

Next, right-click the style sheet record header and copy the sys_id value. You’ll need the sys_id in order to tell the system which style sheet to use.

Now comes the tricky part. You need to determine where to add the link to your style sheet. In the knowledge base example, there are a couple of options. The first is simply to place the following html tag into your article text field while in the HTML code view (where the ‘href’ attribute includes the sys_id for your CMSstyle sheet record).

Shannon’s idea was to leverage the ‘kb_view_custom’ UI macro to include the style sheet link in one place for all articles. You can do this by creating or modifying the ‘kb_view_custom’ UI macro under ‘System UI -> UI macros’ to include the same code as shown above (where the ‘href’ attribute includes the sys_id for your CMS style sheet record).

Here’s one example of what this might look like…

The post Custom CSS style sheets in non-CMS pages appeared first on ServiceNow Guru.

Making the entire Knowledge Base publicly available

In order to make your Knowledge Base available without authentication you need to make the UI components (UI pages and UI macros) that display the knowledge base publicly available. This is done via the ‘Public Pages’ table. Public Pages can be accessed by admins by navigating to ‘System Definition -> Public Pages’ in your left nav. You can activate the module if you don’t see it in the list, or you can simply type ‘sys_public.list’ in the left nav filter to bring up the table.

The ‘Public Pages’ table shows every page in the system that is available to unauthenticated users. Not all of these records are active however. For the KB, you’re interested in the five public page records with a ‘Page’ value containing ‘kb_’. If you’re making your knowledge base public, I suggest making ALL FIVE of these records active. Here’s what they control.

• kb_comments – comments section when viewing a single KB article
• kb_find – knowledge search results page
• kb_home – knowledge home page
• kb_list – topic, category or (sometimes) search listing
• kb_view – individual article page

Require login for public articles

The only problem with the ‘Public by default’ knowledge security model in ServiceNow is that ALL articles end up being public unless you assign a role to them. This leaves you without a way to secure articles to authenticated end-users since they don’t have a role. It’s also inconsistent with the ‘Role’ fields everywhere else in the system…where no roles equals a logged-in end user and the ‘public’ role equals unauthenticated users.

Unortunately, there’s no simple solution with a ‘before query’ business rule or an ACL on the ‘kb_knowledge’ table since the ‘kb_view’ UI page disregards all article security–even though the other KB pages honor it. This means that even if you did restrict an article somehow, any user who knew the URL could access an article that may only logged-in end users should have access to. Here’s what you need to do to fix it.

1Create a new True/False field, named ‘Login required’ on the ‘kb_knowledge’ table by personalizing the back-end knowledge edit form.

2Create a new UI macro named ‘kb_view_custom’ (or edit it if it already exists in your instance). This UI macro is automatically included by the ‘kb_view’ UI page so there’s no additional action necessary to make it work other than to create the macro. See this ServiceNow wiki article for details.

<!--?xml version="1.0" encoding="utf-8" ?-->


//Restrict non-public articles to logged-in users
var answer = false;
if(gs.getUser().isDefault() $[AMP]$[AMP] $[kb.u_login_required]){
answer = true;
}
answer;


<script>
         //Insert a restricted message and remove article contents 
         try{
            $('sys_id').up('td').insert({
               top: '</p>
<table>
<tr>
<td>
<h3>${gs.getMessage('INSUFFICIENT ROLES TO VIEW PROTECTED ARTICLE')} $[kb.number].</h3>
</td>
</tr>
</table>
<p>'
            });
            $('sys_id').up('form').remove();
         }catch(e){}
      </script>

3Finally, just check the new ‘Login required’ checkbox for any article that you want to display only for authenticated users.

The post Controlling Public Availability of Knowledge Base Content appeared first on ServiceNow Guru.

I’m working with a client currently who wants to encourage the use of their Knowledge Base to reduce their ticket load. This, of course, is a common requirement but it’s one that I don’t think is adequately addressed in ServiceNow currently. In this post I’ll share my implementation of their idea. I don’t think it’s a perfect solution, but it might give you some ideas to improve your own process and design. This post shows how you can force a KB search using the standard search dialog whenever a user creates an incident. I’ve designed the solution to work in a standard incident form and within the service catalog so that it can be applied in whatever way you create tickets in your environment.


When I designed this solution, my main concern was to implement a solution that would promote the Knowledge Base search without being completely annoying to the end user. Because of this, I wanted to be very careful about allowing specific control over the event trigger that produces the KB popup window. I also wanted the solution to use as much of the out-of-box behavior as possible.

The solution I decided on was to use a client script to add a ‘blur’ event to the ‘Short Description’ field. The ‘blur’ event for a field runs when the field loses focus. In the case of the ‘Short Description’ field, it runs when somebody clicks into the field, and then clicks somewhere else. I also wanted the script to only run for a new record and only to run when there was an actual value in ‘Short Description’.

From a Standard Form Field

This script can be pasted directly into any ‘onLoad’ client script on a standard form field. The only requirements are that the form includes a field named ‘short_description’ and that field uses the standard KB search icon.

function onLoad() {
//Set the maximum number of times the popup will appear
var maxKBPop = 1;
var kbPopCount = 0;//Only run for new records
if(g_form.isNewRecord()){
//Add an 'onBlur' event to search KB from 'short_description' field
var field = g_form.getControl('short_description');
Event.observe(field, 'blur', function() {
//Only search if there is a value
if(g_form.getValue('short_description') != ''){
//Only pop the search one time
if(kbPopCount < maxKBPop){
kbPopCount++;
customKBPopup(field.id);
}
}
});
}
}
function customKBPopup(me) {
self.fillField = me;
var shortElement = gel(me);
var searchText = shortElement.value;
var url = 'kb_find.do?sysparm_search=' + encodeURI(searchText);
url += "&sysparm_nameofstack=kbpop";
url += "&sysparm_kb_search_table=" + g_form.getTableName();
url += "&sysparm_operator=IR_AND_OR_QUERY";
popupOpenStandard(url, 'kb2task');
}

From a Service Catalog Variable

You can also force a KB search with a catalog variable (on a record producer or catalog item). The script below assumes that you’ve got a string field named ‘short_description’. Because the knowledge icon doesn’t exist for service catalog variables, the script manufactures the icon and link on the fly so that it behaves just like the standard field.

//Add an event handler to pop KB Search when focus moves from Short Description field
function onLoad() {
//Set the maximum number of times the popup will appear
var maxKBPop = 1;
var kbPopCount = 0;
var field = g_form.getControl('short_description');
//Add the KB Search icon
$(field.id).up(1).insert('<a><img class="knowledge" title="Search Knowledge" src="images/icons/knowledge.gifx" width="16" height="16" border="0" /></a></td');
$('status.' + field.id).up('td').setAttribute('colSpan', '3');//Add an 'onBlur' event to search KB from 'short_description' field
Event.observe(field, 'blur', function() {
//Only search if there is a value
if(g_form.getValue('short_description') != ''){
//Only pop the search one time
if(kbPopCount < maxKBPop){
kbPopCount++;
kbPopupSC();
}
}
});
}function kbPopupSC() {
var shortElement = $(g_form.getControl('short_description').id);
var searchText = shortElement.value;
var url = 'kb_find.do?sysparm_search=' + encodeURIComponent(searchText);
url += "&sysparm_operator=IR_AND_OR_QUERY";

popupOpenStandard(url, "kb2task");
}

The post Mandatory Knowledge Search Before Ticket Creation appeared first on ServiceNow Guru.

The first step in creating a widget is to create the UI page to display the widget content. I’m not going to go into the complexities of UI page scripting here, but a UI page to add a knowledge search widget should look like this…

<?xml version="1.0" encoding="utf-8" ?>
<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">
   <g:inline template="kb_header_search.xml" />
</j:jelly>

Next, you’ll need to reference this UI page in a ‘Widget’ record in order to enable users (and you as an administrator) to add it to a homepage. Widgets can be found by navigating to ‘System UI -> Widgets’ and they control the options that people see when they click the ‘Add content’ link on a homepage. There are several out-of-box widgets, but I like to set up a new widget for any instance that I work on called ‘Custom Widgets’ so that I don’t have to modify any out-of-box code. If you’ve got a ‘Custom Widgets’ widget in your system then you’re okay to modify that or create a new one if you choose.

As you might expect, the widget needs to follow a very specific pattern if it is to work correctly. I always use the same pattern that is used for the out-of-box widgets to keep things more standard and simple. It really requires only a couple of things. First, your UI page MUST be named with a ‘render_gadget_’ prefix (notice how I’ve named the ‘render_gadget_kbsearch’ UI page above). Second, you need to modify the ‘sections’ function below to include a line telling the script what the label of the widget will be, and the name of the UI page…minus the ‘render_gadget_’ part. The part of the script below that displays the KB search looks like this…’Knowledge Search’ : { ‘type’ : ‘kbsearch’ }.

function sections() {
   return {
      'Priority 1 Incidents' : { 'type' : 'pri1incidents' },
      'Priority 1 Problems' : { 'type' : 'pri1problems' },
      'Emergency Changes' : { 'type' : 'emergencyChanges' },
      'Knowledge Search' : { 'type' : 'kbsearch' }
   };
}

function sections() {
   return {
      'Knowledge Search' : { 'type' : 'kbsearch' }
   };
}

function render() {
   var type = renderer.getPreferences().get("type");
   var gf = new GlideForm(renderer.getGC(), "render_gadget_" + type, 0);
   gf.setDirect(true);
   gf.setRenderProperties(renderer.getRenderProperties());
   return gf.getRenderedPage();
}

function getEditLink() {
   return "sys_ui_page.do?sysparm_query=name=render_gadget_" + renderer.getPreferences().get("type");
}

Once you’ve set up your UI page and Widget record correctly you can open up a homepage and click the ‘Add content’ link in the top-left corner of the page. You’ll see your widget category name, ‘Custom Widgets’ in the first box, followed by the name of your ‘Knowledge Search’ widget in the second box to add to a homepage.

The post Creating a Knowledge Search Homepage Widget appeared first on ServiceNow Guru.

How do I hide this form icon for some users but not others?

This request can apply to different types of icons, but is often asked about the ‘Search Knowledge’ (KB Search) icon or the ‘Suggestion’ icon that shows up in a default ServiceNow installation next to the ‘Short Description’ field. This article shows how you can remove this icon (or any other icon image) selectively using client scripts.

Here’s the script. This example is designed to be used in an ‘onLoad’ client script on the ‘Incident’ table. The main point of the script is to find the icon and hide it if the user does not have the ‘itil’ role. For a lot of HTML elements you can use a specific element ID to target and hide the element directly. In this case (and in the case of most icons in ServiceNow) the element in question doesn’t have a specific ID attribute so you have to go about your task a little bit differently.

The script goes through the entire page and finds any ‘A’ tags on the page (indicating an HTML link). Then it examines all of these elements one-by-one to see if any of them contain an ‘innerHTML’ attribute containing ‘knowledge.gifx’ — the image name of our icon. Once we’ve done that we know we’ve found our element and we can hide it with this code…

elmt.hide(); //’elmt’ refers to the found ‘A’ tag containing the icon

You can easily customize this script to hide an icon for different roles or a different icon completely by modifying the ‘g_user.hasRole’ and ‘knowledge.gifx’ sections below.

function onLoad() {
   //Hide the kb icon for users that do not have the itil role
   var isITIL = g_user.hasRole('itil'); //Check if user has itil role
   if(!isITIL){
      try{
         //Find the knowledge icon 'a' tag and hide
         $$('a').each(function(elmt) {
            if(elmt.innerHTML.indexOf('knowledge.gifx') > 0){
               elmt.hide();
            }
         });
      }catch(e){}
   }
}

If you know that the KB icon will be the only (or first) KB icon on the form, you could accomplish the same thing in one line of code…

$$('img[src="images/icons/knowledge.gifx"]')[0].hide();

Hiding the ‘Suggestion’ icon for a field

The suggestion icon is a bit simpler because it has an ID to target. Here’s a script you could use to hide the suggestion icon from the comments field if the table is not ‘incident’. The script would need to be added to an ‘onLoad’ client script on the ‘Task’ table with the ‘Inherited’ checkbox checked. Just change the ‘fld’ variable value for use with another field!

function onLoad() {
   //Identify the table and the field name
   var tbl = g_form.getTableName();
   var fld = 'comments';
   if(tbl != 'incident'){
      //Hide the suggestion icon for the field
      $('lookup.' + tbl + '.' + fld).hide();
   }
}

The post Hide ‘Search Knowledge’ or ‘Suggestion’ Icon in ServiceNow appeared first on ServiceNow Guru.