$sp is not defined" only through AI Search after the Australia patch — the widget works fine everywh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sunday
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!