sbyr99
Kilo Contributor

Question on creating a Decision tree in knowledge base

I did an investigation (and implementation) on a decision tree in the knowledge base a while back, maybe I can help. What is your question?

Hi Seb, thanks for coming . The question is exactly that how did you implement it in Knowledgebase as there are third party tools that can do it but i would like to know the process of doing this in SN

Hey Steven.

if understand correctly.

We need to Review with SMEs(Subject Matter Experts) before   publishing the Knowledge article.

Hello Sebastien, can you please ome back to relating this issue...

Of course sbyr99, see below. Let me know if you have any questions on this.

I considered a few elements for implementing a decision tree in knowledge management.

Relationship (tree) definition

Dedicated article relationship (RECOMMENDED)

This solutions creates a dedicated relationship between knowledge articles, where you define a m2m table that defines the parent-child (question-answer) relationship between articles. So your "tree" is defined by one article and its children in this table. After that you modify the knowledge UI page to display all children ("answers" if you work question answer based in your decision tree) in a table/list on the bottom of the page with the link to the appropriate article. You have to build in some dynamic URL creation if you view the knowledge articles in popups. In addition you can choose to link to the parent (e.g. on top of the page).

The advantage is that this is the most flexible, since it's data driven and you can modify relationships without changing the article. The drawback is that you have to modify the (OOTB) UI page for knowledge articles and it requires an additional table.

Inline article relationship

In this approach you do not actually create a relationship between the articles, but you just include the link to the next article (answers/children) in your article HTML. This is not very flexible in terms of defining your "tree", but it has the advantage that knowledge administrators can include the links more easily and you don't have to change the knowledge UI page. The inability to have your tree defined as a set of parent-child relations is a big drawback here.

Data structure

Using any of the two relationship structures above, the hierarchy of your knowledge articles is of little importance for the decision tree, you might still want a hierarchy/categorization for the articles itself.

However, if your decision tree has clear "levels", you might want to structure your knowledge hierarchy/categorization according to this. So that means you have one   "root" category, with a "level 1" category, "level 2", etc.

This may help in building your knowledge articles and also simplifies browsing, since you can see on which level in the tree you are by the category.

Root

You need to define some starting point for your decision tree ("root"). This can be via either a direct link to the root article, e.i. in your portal or on your (intranet) page. Other options are either creating a tag "root", which really helps in searching/noticing "root" articles in your knowledge search. Another option is following the data structure and creating a "root" category.

I'm not saying these are the only options nor that they may be better solutions. If someone has a better proposal, or an addition to the described options and/or elements, I would love to hear that.

This document was generated from the following discussion: Question on creating a Decision tree in knowledge base

Comments
x191034
Giga Contributor

With the Madrid release ServiceNow has come up with a decision tree feature. Please see below link:

 

https://developer.servicenow.com/blog.do?p=/post/decisiontrees/

 

Regards,

Sachin

scjkal485
Giga Contributor

They have very little need to look up unless they see movement. If you get even six toes off the floor and continue to be nonetheless, it gives you a massive benefit on treestandranger.com.

Version history
Last update:
‎02-05-2018 03:25 AM
Updated by: