Knowledge article dynamic linking

Beth11
Giga Guru

So this is a problem I'm dead certain someone else has had to tackle and answer. I'm importing and converting a very well-written and maintained knowledgebase. Images, videos, all of that is tackled, but what I can't seem to puzzle out is links between KB articles.

There are a lot of them, and the problem isn't as straightforward as it might at first appear. The way I see it, I've got two hurdles I need to overcome: Versioning and Service Portal.

Versioning, by itself, is not insurmountable. The system itself provides a way, here: links that use the KB number.

https://<instance>.service-now.com/kb_view.do?sysparm_article=KB0000030

Which, awesome, this will always link to the latest version of the article. But when you throw Service Portal into the mix, it falls apart for a few reasons:

  1. Service Portal recognizes https://<instance>.service-now.com/sp/kb_view.do?sysparm_article=KB0000030 well enough, but it does so by stripping out the /sp/ and loading the kb article in the default ITIL view. This won't work for us; we need to preserve the SP branding and nagivation bars.
  2. No matter how an article is called, the url displayed is always in this format:   service-now.com/sp?id=kb_article&sys_id=d15de43187032100deddb882a2e3ec7d
    This makes linking the latest article from a web browser just about impossible.
  3. The links in the article itself won't work properly. Instead of sending the user to the Service Portal view of the article, the link will send them to the unadulterated (no navigation menus or other kibble) link in the full application view. This is undersable because we don't want end users in the itil view at all, and if they somehow get there showing them zero context is jarring and unhelpful at best.
  4. If I were to include all of these links, somehow, in a way that worked for Service Portal, now I have the issue where I'm breaking the ITIL users if they try to browse articles and forcing them out into Service Portal. This is also less than ideal.

So, to recap:

Currently, the kb_view.do? method of linking articles works to counteract the versioning problem. But Service Portal vs ITIL is still an issue that I don't see an easy way around. So my question is this:

  • Is there a way to configure kb_view.do or create my own custom linking mechanism?
  • If I do so, does anyone have a recommendation on programming it to detect if the user is on SP/Full view?

Thanks in advance for any help or suggestions you might have.

UPDATE: Having unsucessfully tried modifying the UI page and creating a processor to intercept the kb_view references, I'm starting to think that I need to disable the html sanitizer on the knowledge text view and use a javascript onclick for routing... It's either that or own both the SP widget and the UI Page for displaying knowledge articles. I hate to mess with the sanitizer, but my options are looking a little thin at the moment.

1 ACCEPTED SOLUTION

Beth11
Giga Guru

Since this has become something of a hub for this conversation:

As far as I know, there's still no good answer for this problem. Owning the KB view widget partially solves the problem, but there are other widgets that start to have issues (like kb_header) and long term it feels like I'm going to own more and more of this page if I want everything to work right. 

Realistically, everything I do is a band-aid, since we don't have good visibility on some of the versioning code to fix the problem at the source. If/when SN comes out with a better solution, I'll circle back and update this answer, but right now check the comments for several potential workarounds for this problem.

View solution in original post

22 REPLIES 22

Thanks for your thorough reply and offering help Beth! I will investigate it further with our dev team and see what can be done.

Have a great day!

Janel
Kilo Sage

Anyone run across anything that if you're linking to a KBA from a non-KB article, to stick with the same UI? 

For example, I have a catalog variable with help annotation that has "See KB001234 for more information". 

find_real_file.png

The user clicking the link may be in portal, they may be in UI16, I do not know.  I also do know which portal they may be using so always linking to "/sp?id=" isn't going to be super helpful either. 

What I do know is that the Copy Permalink that our knowledge contributors use today always points to UI16 (that is where they are working out of, so it makes sense).  It is a crazy expectation from ServiceNow that I now need to go manage those people to scold them about using proper URLs when the systems own "Hey, copy a link to me!" is UI16.  Argh!  How frustrating!

We do have the knowledge portal plug-in installed.  I was going to try a page route, but the kb_view in the Route from is a reference to a portal page, not a UI page, so that isn't helpful.

I feel like there is a huge gap I'm missing here...

Randall King
Tera Expert

We are getting ready to launch into production this summer, and we're running the San Diego release. We are encountering the same problem regarding people who click a link from one KB article to another. Either our support agents will be sent to the service portal (kb_article_view) or customers will be sent to the platform UI (kb_view).

We are going to link from one article to another using kb_view for now, and we'll just live with customers being sent to that UI. The saving grace is that we can use target=_blank to send them to a new tab, making sure that they keep the tab with the service portal still open. However, we would like to find a long-term fix for this odd problem. Has anyone else found something that works well?

Ideally, a KB link would know in which interface the person is presently and send them to that UI.