Service Portal Search Stops Work for Non-Admins in Zurich

jmiskey · ‎09-16-2025

We are in the progress of upgrading from Xanadu to Zurich. We promoted our DEV and TST instances to Zurich, and one thing we have noticed is that the Search functionality on the Service Portal no longer seems to work. It was reported to us by a user, and when we try it as an admin, it seems to work. But if we impersonate a non-admin user, it does not seem to work. We just get a message like this:

I am guessing that maybe they updated some ACLs or something, though I am not sure which ones. I am not sure if the change was actually done in Yokohoma or Zurich (since we skipped Yokohoma).

Does anyone have any information on this, or what we need to do to re-enable the Search functionality to work for non-admins again, like it always used to in the past?

jmiskey · ‎09-17-2025

Upon further review, it appears that the issue may be more related to the Custom Service Portal wire frames we had made for us by a 3rd party vendor. We tried it on the out-of-the-box Service Portal in our PDI, and it did not exhibit that behavior. So I don't think it is an issue with the ServiceNow release. The release may have changed things (maybe some new ACLs or something like that), but it appears that it did not break the OOTB Service Portal, but instead broke our customized version of it.

Thanks for looking anyway!

View solution in original post

YummyAmericano · ‎10-14-2025

Try this method: @mleonard @jmiskey

Create a new ACL with these values:

Type: Record
Operation: Read
Name: sp_search_source

Set Security Attribute Condition

Condition Type: Existing
Security Attribute: UserIsAuthenticated
Leave Roles Empty: Do not add any roles. The security attribute will handle access.
Leave Script Empty: You don’t need a script if you're using the security attribute.

Save the ACL

Disable the Old ACL

Find the original READ ACL on sp_search_source.
Set Active = false.

Test the Change

Impersonate a non-admin user.
Run a search in the Service Portal.
Confirm that results appear.

Hit 👍 if this solution is helpful! 😉

View solution in original post

jmiskey · ‎10-08-2025

So I found the Read ACL on m2m_sp_portal_search_source, and changed the role from "sp_admin" to "public", and unfortunately, it made no difference. Are you sure that they didn't make any other updates to any other ACLs?

By the way, the thing I am trying to look up is a Catalog Item, if that matters. I do see a Read ACL on that for the public role as well.

Nadia F · ‎10-08-2025

Check your Search widget (we use now/nav/ui/classic/params/target/sp_widget.do%3Fsys_id%3Db8c57073cb10020000f8d856634c9cfc%26sysparm_record_target%3Dsp_widget) to see what ACLs might be used by GlideRecordSecure.

Nadia F · ‎10-08-2025

As part of the troubleshooting, we also set Active to false for m2m_sp_portal_search_source Operation: query_range added by QueryRangeACLAuditor. Once we got our portal search to work, we re-ran the QueryRangeACLAuditor that readded the m2m_sp_portal_search_source Operation Query_range. It had no impact on search at that point.

Matt O_1 · ‎10-08-2025

This worked for me. I cloned the search page widget, updated all the gliderecordsecure back to gliderecord and then replaced the OOB search page widget.

mleonard · ‎10-14-2025

Any fix for this? We are experiencing the exact same problem. I would be surprised if it was ACL's because this is just an upgrade so surely all existing ACL's remain in place? Therefore the search should work the same as it always has?

We've checked our GlideRecord and it is not set to GlideRecordSecure so should allow non admin roles to complete the search?