Unexpected Behavior: Catalog Variable Showing Another User’s Phone Number

SeijiNscr · 3 weeks ago

I encountered an unexpected issue and would like your help.

I created a catalog item in ServiceNow that displays the logged‑in user's own information and allows them to edit it if necessary.
However, one user reported that the phone number shown in the catalog actually belonged to another person.

The field is populated by a variable whose default value is:
javascript&colon; gs.getUser().getRecord().getValue('phone');

The users are on different devices, but they access ServiceNow from the same global IP address.
Interestingly, the user whose phone number appeared had logged in earlier on the same day.

This looks like a possible session mix‑up, but I'm not sure.

Is it possible for gs.getUser() to return the wrong user in this situation?

kateparker7 · 3 weeks ago

It’s understandable why this is worrying—session or cache "bleeding" is a major concern for any admin. Since cache.do fixed it, the issue wasn't with your logic, but with how the server or the browser held onto a previous response.

Here are a few likely culprits for why this happened:

Dynamic Cache on Catalog Items: Sometimes, if a page is cached at the edge (CDN) or by the mid-tier, the result of a server-side call like gs.getUser() can get "stuck" for a specific IP address. Since you mentioned they share a global IP, the network might have served a cached version of the page intended for the previous user.

The "gs.getUser()" timing: While gs.getUser().getRecord() is standard, it occasionally behaves oddly in default value fields if the session hasn't fully initialized. A more robust way to handle this is using a Catalog Client Script (onLoad) to fetch the data via g_user or an asynchronous GlideAjax call. This ensures the data is fetched fresh for the active session every time the form loads.

Browser-level Auto-fill: It sounds simple, but check if the user has "Auto-fill" enabled in Chrome/Edge. If they previously helped another user or the browser "guessed" the phone number based on a similar field ID, it could have overwritten your default value visually.

To prevent this from recurring, I’d suggest moving away from the "Default Value" field and using an onLoad Client Script with a GlideAjax call. It’s slightly more work to setup, but it’s much more reliable at ensuring the data is unique to the current session.

View solution in original post

Ankur Bawiskar · 3 weeks ago

@SeijiNscr

should not occur ideally.

Did you ask that user to clear instance cache using cache.do and then logout and login again?

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader

SeijiNscr · 3 weeks ago

Hi @Ankur Bawiskar

Thank you for your quick reply!
I asked the user to clear the instance cache using cache.do, then log out and log back in, and that resolved the issue.
However, I'm still unsure what caused the wrong user data to appear in the first place, so I'm a bit worried about the possibility of it happening again.
If you have any ideas about the root cause, I'd appreciate any insights.

Ankur Bawiskar · 3 weeks ago

@SeijiNscr

Glad to know that my approach worked

it was a cache issue. it does happen sometime

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader

Ankur Bawiskar · 3 weeks ago

@SeijiNscr

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader