Error mapping fields in custom kb templates for AI Search

Kristin J
Mega Sage

Hello there!

While configuring index sources for AI Search, I'm having trouble with our custom knowledge article templates. We have a custom How-to template, which has multiple fields. When mapping the fields, I am following the pattern of the OOB templates, mapping relevant fields to "text". 

The first field I add works fine, but the second gives me an error: 'text' already mapped

The oob templates have more than one field mapped to text, so I'm not sure what I'm missing here. Any advice is appreciated, thank you!

Cheers,

Kristin

1 ACCEPTED SOLUTION

ServiceNow Tec2
Mega Sage
This has been resolved by ServiceNow Technical Support. Please refer to KB1007082 for more information.

View solution in original post

8 REPLIES 8

I signed in to the support portal and searched for that KB article number. It just redirects me when I try to view it.
We are a government community cloud (GCC) customer, and so I have access to the hiwave portal. I signed in there and searched, and I can view the article there. However, the content is essentially the same as the doc linked above. It doesn't have anything other than that content, and nothing related to this problem.

This article is no longer available and I am having similar issues adding a new field to AI search for indexing. Is there a new reference for how to do this?

 

Thanks!

Here is some information from a case that we had opened with ServiceNow Support regarding this. It has a lot of information that helped us understand how this works and how to deal with it. The information is from seven months ago.

 

I have received a response back from our Dev team regarding the Task I had submitted to that team with some of your questions. It appears this issue is actually a known Issue in the system with supporting the map_to in child table cases. This is why the UI won't allow it in certain cases (and thus generates the errors in attempting to add certain field mappings). The Developer indicated that they have submitted an internal STRY record to update this functionality so as not to restrict this mapping, however, as that is an "enhancement" to current functionality and will need to be Engineered and then included in an update release package once it has been completed, you will probably need to use a work-around until such time as that functionality has been realized and incorporated into the product.

A potential work-around, as suggested by the Developer team, is as follows:

Concept: Copy the value of the field that needs to be mapped (for example u_kb_template_ithc_policy_and_procedure) field to the "text" field on records in the base template. This will allow the regular field mappings and EVAMs will apply.

In order to do this the customer might do something such as the following:

1) Create a Business Rule to copy the content each time the "u_kb_template_ithc_policy_and_procedure" is altered.

2) Run a script to copy the data on all existing records from "u_kb_template_ithc_policy_and_procedure" to "text".

3) ReIndex the Knowledge Table Indexed Source.

I had also posed several questions of the Developer based on the issues we were experiencing and our dialogue in this Case. The Developer was thus able to provide the following answers to those questions:

Question: Customer is asking, if only one field can be assigned to this 'text' field, how do other fields that should be searchable get indexed?

Answer: This limit is not necessarily rigid, but really only applies to child tables of the parent template. One can map multiple fields to "text", however those fields must just be on the parent table. All string fields on a record are searchable, just the content displayed in the Search Response card only shows the information as displayed in those fields mapped to "text".

B. How come some templates allowed multiple fields to be mapped to the 'text' field but others do not and generate the given error message?

It has to do with the root_table_only parameter on the "map_to" attribute's configuration. It only allows for parent table fields to map "to" the "common" fields. (IE: text, title, etc.) Child tables are restricted "from" mapping to the common fields. We are looking at addressing this current limitation in future releases.

C. If all fields are automatically indexed (if that's true), what is the purpose of mapping to the 'text' or other fields in the AI Search system?

The purpose of mapping to common fields is for the UI display so that all search response cards have a way of displaying the multiple table results in a "unified way". For example the "title" and "text" from a KB come from different fields then they do from a catalog item.

Please let me know if this information was able to assist you regarding the issue/questions you had or if you still had questions or issues,

Eric Weischedel

This is awesome, thank you very much!