$sp is not defined" only through AI Search after the Australia patch — the widget works fine everywh

[oussamaghaz]

Hi everyone,

I'm hoping someone has run into this. Everything in our Employee Center Pro was working fine, we took the Australia patch3-hotfix1 (mid-June), and the next morning AI Search started throwing a server error: "$sp" is not defined, coming from the OOB Now Assist Self Service widget (sp_widget 634bcbc59ff20210210e089c8a0a1ce1), right at its first $sp.getPortalRecord() call.

It hits every user. The instance is a demo instance.

The part that's driving me a bit crazy: **$sp works perfectly everywhere else.** The rest of the portal renders fine, other widgets using $sp are happy — it's only when AI Search renders *this* widget that $sp suddenly isn't there. For reference, other Employee Center pages that use $sp (e.g. the HR To-Dos page) render perfectly — it's strictly the AI Search render path that fails. So to me this smells like a rendering-context problem, not a broken widget.

Here's what I've already chased down: - I checked the Upgrade Details (sys_upgrade_history_log). The widget shows up as **Updated, changed=true**, delivered by patch3-hotfix1 — so the patch genuinely overwrote the base widget. -

My first instinct was to diff the old vs new widget code. Dead end: there's **no previous version stored** in sys_update_version, because the widget was never customized — so the upgrade refreshed it in place and there's nothing to compare against.

- I then looked at what *else* the same patch run applied (changed=true): a bunch of **Data Broker Server Scripts**, a **Composite Data Broker**, an **"Instance with Search"**, and several **Angular providers** — basically the whole AI Search render path moved in this patch. - The sp_instance → column → row → container → page chain is intact, and the AI Search profile/sources are published. Nothing obviously broken on the config side.

My working theory is that the patch rewired the AI Search path so the widget's server script now runs **outside the Service Portal rendering context**, which is the only thing that injects $sp (GlideSPScriptable). If it's invoked through a data broker or the AIS composite renderer instead, $sp would simply never be there. So, a few questions:

- Has anyone hit "$sp" is not defined on the Now Assist Self Service widget after the Australia (or Yokohama) patch?

- Is there a known PRB where the AI Search results path calls this widget without an SP context?

-Any idea how to resolve it?

I'm pulling the full server stack trace right now and I'll drop it in the comments once I have it. Thanks a lot for any pointers!

[DJ Wolfson]

Hello, our team just ran into this issue, although from a slightly different source. We have a custom scoped application with a Catalog Item. We're finding the same error and traced it the Global Script Include function:

GlobalServiceCatalogUtil.getEngagementChannel();

Inside the function, the following line is the source of the error:

var portalGr = $sp.getPortalRecord();

Do you have any updates on your investigation?

[Daniel Sampaio]

Hello,

We are seeing the same issue after upgrading to Zurich Patch 10 Hot Fix 3.

The error is also coming from the OOB Now Assist Self Service Widget:

Error:
Server JavaScript error "$sp" is not defined.

In our case, the failing line is where the widget calls:
$sp.getPortalRecord().getUniqueValue()

This is happening in both our DEV and TEST instances after the update, so it looks like a regression in the AI Search / Now Assist rendering path rather than a local portal configuration issue.

I will open a case with ServiceNow and will update this thread if we get any confirmation, workaround, PRB, or fix.

[Harihara Sudha1]

Solution Proposed by ServiceNow:
A code change introduced in the Now Assist Self Service Widget (634bcbc59ff20210210e089c8a0a1ce1) in Zurich Patch 10 contains a regression that causes the $sp Service Portal API object to be undefined when the widget script runs.

A permanent fix for this issue is included in the Brazil release. Approval is also pending to backport the fix to Zurich Patch 12.

SN development team has provided below workaround that will help resolve the issue on the instance
The workaround is to revert the Now Assist Self Service Widget to the version that shipped with Zurich Patch 9, which does not contain the regression. There are 2 options for you.

Option 1: Import the attached update set sys_remote_update_set_d8e901b10de14b10f8773f54f655bd2d.xml , to resolve the issue.

OR

Option 2: Import the previous version of the OOTB Now Assist Self Service widget attached ZP9_OOTB_sp_widget_634bcbc59ff20210210e089c8a0a1ce1.xml

Please test in sub prod instance before applying changes to production. 

Thank you

Harihara Sudhan M S

[Daniel Sampaio]

Hi,

We opened a case with ServiceNow Support and they confirmed this is a known issue: **PRB2038055**.

From the information provided, this appears to be a regression introduced in the **OOB Now Assist Self Service Widget** after **Zurich Patch 10 Hot Fix 3**, where the `$sp` Service Portal API object becomes undefined when the widget script runs through the AI Search / Now Assist render path.

ServiceNow mentioned that a permanent fix is included in the **Brazil release**, and that approval is pending to backport the fix to **Zurich Patch 12**.

For anyone affected, I would recommend opening a ServiceNow Support case and asking them to link it to **PRB2038055**, so they can confirm the appropriate workaround for your instance.