- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-05-2018 02:09 PM
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:
- 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.
- 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. - 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.
- 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.
Solved! Go to Solution.
- 15,454 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-19-2019 08:56 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-12-2019 12:01 PM
Thank you Beth for this very detailed write up. It seems we are all suffering from the same issues. That is sadly comforting. I am HIGHLY interested in any solutions you obtain for this, and I in-turn will share if we obtain any. In my opinion, based on so many shortcomings is that SN is NOT a useful KM solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-06-2019 02:36 AM
You can retain branding by using the Madrid Knowledge Base portal plugin (com.snc.knowledge_serviceportal). This adds a new portal (/kb) designed to replace the Service Portal knowledge base page.
Articles can then be permalinked directly to the portal, e.g.:
https://xxxx.service-now.com/kb?id=kb_article_view&sysparm_article=KB0010528
A copy permalink button appears at the bottom of articles within this portal:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-13-2019 08:35 AM
I believe our payers on versioning (and frustrations with this) have been answered in New York. See:
Haven't tested this out yet but if what I'm reading is right it's the answer we've been looking for for years. This is the fella:
Let me know if anyone has success with this.
Regards
Paul
Regards
Paul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2020 01:58 AM
Old thread but I'm guessing it's still a problem? I at least have not found a way to create durable links between articles (preferably using the internal/ITIL view kb_view permalink) that directs you to the same UI you're viewing it from.
We tried using the permalinks from the portal but then there was a change on the portal URL and all links broke.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-02-2020 02:37 PM
Hi Eric,
Yes, we still have our custom solution in place. We added a custom parameter (kb_number) and check for that parameter as well as the default sys_id; if we see kb_number defined, then we use a quick gliderecord on the server script for the article's sys_id. We then feed that into the default code for the widget. This invoved owning the header and body widgets (which has proved a pain when we wanted to implement knowledge blocks!)
A smoother method I've ended up using elsewhere is this:
- Accept any sys_id
- Check to see if the retrieved article is the latest version
- If it's not, go retrieve the latest and use it instead.
It's got the benefit of being seamless and not requiring you to own everything that ever generates a link to articles, just the things that process them (the header and and the body only, I think; if memory serves, the comments section gets the article information from the header, though that may have changed.) It's allowed me to greatly decrease the footprint of widgets we own related to this, and allows for more graceful handling of the links generated by contextual search.
Let me know if you need a hand and I can probably whip up some quick demo code on my developer instance.