Redirecting Knowledge Results in AI Search for Next Experience

After migrating ServiceNow’s Next Experience global search from the legacy Zing search to AI Search, I ran into a small but surprisingly awkward problem.

Knowledge results worked perfectly well, but when a user clicked an article from the global search results, ServiceNow opened it using the standard Knowledge view:

/kb_view.do?sys_kb_id=...

For our users, that wasn’t the experience I wanted. We already have a dedicated Knowledge Portal, so ideally those same search results should open there instead:

/kb?id=kb_article_view&sys_kb_id=...&table=kb_knowledge

What ServiceNow suggested

I raised a case with ServiceNow Support and was initially pointed towards the EVAM/Declarative Action configuration. The recommendation was to customise the OOTB navigation Action Payload Definition and the Knowledge EVAM action assignment so that Knowledge results used a different destination. I could find all of the records they referenced, but the suggested route didn’t really line up with how Next Experience global search was building the URL. In particular, the navigation action simply consumes {{navigation_url}}, and trying to build a portal URL dynamically inside the payload resulted in placeholders such as {{sys_id}} being treated literally rather than substituted.

What actually worked

While looking through the Next Experience Search Application Configuration, I found an existing Search Script Post Processor used for Platform Analytics results. That script used record.setUrl() to override the result destination before EVAM handled the click action.

That turned out to be exactly the right mechanism.

Rather than customising EVAM navigation at all, I created a Knowledge-specific Search Script Post Processor:

function process(record) {
    if (record.getTable() === "kb_knowledge") {
        record.setUrl(
            "/kb?id=kb_article_view&sys_kb_id=" +
            record.getSysId() +
            "&table=kb_knowledge"
        );
    }

    return;
}

That means the standard EVAM navigation action can remain untouched and continue to use:

{
    "table": "{{table}}",
    "sysId": "{{sys_id}}",
    "url": "{{navigation_url}}"
}

The post-processor simply changes the URL on Knowledge results before they reach EVAM.

The end result

The flow is now:

AI Search
    ↓
Knowledge result returned
    ↓
Search Script Post Processor
    ↓
record.setUrl(...)
    ↓
navigation_url contains the Knowledge Portal URL
    ↓
OOTB EVAM navigation action
    ↓
Knowledge Portal

This is much cleaner than customising the shared navigation Declarative Action, and it keeps the change scoped specifically to Knowledge results.

It also means incidents, requests, users and other result types continue to use their existing navigation behaviour unchanged.

In the end, the answer wasn’t to change how EVAM navigates. It was to change the URL one step earlier in the AI Search result pipeline.

Related Posts