Problem Statement
The AIS (AI Search) Topic Search widget in Employee Center returns no results or incorrect results when users search within taxonomy topic pages, particularly impacting multilingual deployments. The search works inconsistently — functioning on parent topics but failing on children, or working in English but breaking in other languages.
Root Cause
The topic_path field is auto-generated by the Business Rule "Topic - generate full path" and stores the hierarchical path (e.g., "Technology services / Hardware / Computers"). AI Search indexes connected content using this path, breaking it into individual topic facets. When users search, the widget passes the current topic as a facet filter to match against indexed content.
The critical failure point: when the topic_path field becomes corrupted or untranslated, the facet filter passed to AI Search doesn't match the indexed topics, returning zero results.
Known defects triggering this:
- PRB1733229: When a parent topic's
nameis translated, the Business Rule incorrectly regenerates English subtopic paths, omitting the current topic name from its own path - PRB1710423: The Business Rule doesn't handle async execution correctly (marked "Won't fix," tracked by EPIC1083974)
- PRB1823459: When system-wide default language preference is set to non-English, AI Search indexes English documents with translated topic paths, so English facet filters fail to match
The topic_path field is hidden by default and not editable, making corruption difficult to detect until search breaks.
Impact on Non-English Users
Primary impact: If topic_path isn't translated for a given language, searching in non-English topic pages fails completely. Example: A Japanese user viewing the "コンピューター" (Computers) topic page searches for "Apple" — AI Search receives "コンピューター" as the facet filter, but the indexed catalog item has topic_path = "Technology services / Hardware / Computers" (English only). No match → no results.
Secondary impact (PRB1823459): When the instance has a non-English default language preference, AI Search indexes English documents with translated topic paths. Later, English users searching English topic pages pass English facet filters that don't match the translated indexed paths. This breaks English search while attempting to support other languages.
Cascading effect: Translated parent topic names corrupt child topic paths (PRB1733229), so fixing one language's translation can break the path hierarchy for English, propagating failures across the entire taxonomy tree.
Current Resolution (Manual Fix — Documented in KB1649376)
Step 1: Run a background script to regenerate topic_path by replicating the Business Rule logic:
var topics = [SYS_IDs]; // affected topic sys_ids
topics.forEach(populateTopicPath);
function populateTopicPath(topic_sysid) {
var topicgr = new GlideRecord('topic');
topicgr.get(topic_sysid);
var path = topicgr.getDisplayValue("name");
if (topicgr.parent_topic) {
path = topicgr.parent_topic.topic_path + " / " + topicgr.getDisplayValue("name");
}
topicgr.topic_path.setDisplayValue(path);
topicgr.setWorkflow(false);
if (topicgr.update()) {
new global.TaxonomyUtil().updateChildTopicsPath(topicgr.sys_id, path);
}
}
Step 2: Verify the regenerated topic_path in both English and all translated languages.
Step 3: Reindex AI Search indexed sources (catalogs, knowledge) from the Employee Center Search Application to re-ingest topics with corrected paths.
For PRB1823459: Remove the system-wide non-English default preference and reindex.
Limitations of this approach:
- Requires identifying every affected topic sys_id (not always obvious)
- Manual verification across all languages
- No prevention — paths can corrupt again on next parent translation
- Reindexing is slow and impacts search availability
- Doesn't address the root Business Rule defects
Recommended Solution: Localization Framework for Taxonomy Translation
Rather than manually editing sys_translated_text records for each topic (which causes the PRB1733229 path corruption), implement the Localization Framework artifact for centralized, workflow-driven taxonomy translation. This eliminates manual table edits and provides structured translation tasks.
Benefits
- Prevents path corruption: Translations go through LF task review before publishing, catching issues before they break AI Search
- No direct
sys_translated_textediting: Translators work in Localization Workspace UI, reducing errors - Batch processing: One "Request Translations" action on a taxonomy extracts all child topics into a single task
- Machine translation integration: Optional MT providers (Google, DeepL) reduce manual effort
- Update set packaging: LF tasks bundle translations for promotion across instances
- Audit trail: Full translation provenance and task history
Configuration following:
1. UI Action
Adds "Request Translations" button to the taxonomy form.
function renderLanguagePickerModal() {
// we need to call the modal
var dlg = new GlideModal('sn_lf_language_picker');
dlg.setTitle(getMessage('Request Translations'));
dlg.setPreference('sys_id', g_form.getUniqueValue());
dlg.setPreference('table_name', g_form.getTableName());
dlg.setPreference('request_type', "form");
dlg.setPreference('focusTrap', true);
dlg.render();
}2. Processor ScriptLF_Topic processor queries all topics belonging to the selected taxonomy (taxonomy = sysId), then calls processTranslatableFieldsForSingleRecord() to extract name, description, and topic_path (all Translated Text field types) for each topic. Processes the entire taxonomy tree in one extraction.
var LF_Topic = Class.create();
LF_Topic.prototype = Object.extendsObject(global.LFArtifactProcessorSNC, {
category: 'localization_framework', // DO NOT REMOVE THIS LINE
/**********
* Extracts translatable content for a topic and its child topics.
* params.tableName Artifact table ('topic')
* params.sysId sys_id of the topic the artifact was launched on
* params.language Target language
* @return LFDocumentContent
**********/
getTranslatableContent: function(params) {
var tableName = params.tableName;
var sysId = params.sysId;
var language = params.language;
var lfDocumentContentBuilder = new global.LFDocumentContentBuilder("v1", language, sysId, tableName);
var taxTopic = new GlideRecord('topic');
taxTopic.addNotNullQuery('taxonomy');
taxTopic.addQuery('taxonomy', sysId);
taxTopic.orderBy('name');
taxTopic.query();
while (taxTopic.next()) {
lfDocumentContentBuilder.processTranslatableFieldsForSingleRecord(taxTopic, taxTopic.name.toString(), "Name");
}
return lfDocumentContentBuilder.build();
},
type: 'LF_Topic'
});3. Artifact Config
Defines the proto_taxonomy artifact on the taxonomy table, linking to the LF_Topic processor. Internal name matches the UI Action condition.
Deployment
- Create UI Action, Processor Script and Artifact in Global scope
- Activate the artifact in Localization Framework Settings
- Configure translation preferences (Human/Machine/Hybrid workflow)
- Navigate to a taxonomy record → click "Request Translations" → select target languages → LF creates a task containing all child topics
- Translators review/edit
- Publish → translations write to
sys_translated_textcorrectly - After publishing, follow KB Step 3 (reindex AI Search sources) to ensure newly translated paths are indexed
Ongoing Workflow
- New topics: After adding topics to a taxonomy, run "Request Translations" again — LF detects new/changed content automatically
- Path corrections: If paths corrupt due to PRB1710423, regenerate via the KB background script (Step 1), then "Request Translations" to retranslate the corrected paths through LF
- Version upgrades: When EPIC1083974 delivers a permanent Business Rule fix, LF-managed translations remain intact
Conclusion: The Localization Framework artifact shifts taxonomy translation from fragile manual table editing to a governed, scalable workflow. The uploaded configuration is ready for production use and directly addresses the root cause of AIS Topic Search failures in multilingual environments.
