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

[SeijiNscr]

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: 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?

[Ankur Bawiskar]

@SeijiNscr 

I still believe it was a cache issue which occurs sometimes.

If it still happens sometime later then you can do thorough investigation and raise a case with ServiceNow if you are unable to figure out the root cause

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

[Ankur Bawiskar]

@SeijiNscr 

I believe your issue has been resolved.

Request you to close the thread by marking appropriate response as correct.

[GlideFather]

It sounds to me like there might be some issue with phone formatting, 

please @SeijiNscr could you ensure and/or compare phone numbers with other users?

Phone number is starting with the country code that can be transcript as (+351) or (00351), then the actual phone number 12345678 or (123) 456789 or 123 456 789... or I don't know what else.

And I am already out of ideas, good luck! :))

[kateparker7 · Accepted solution]

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.

[Tanushree Maiti]

Hi @SeijiNscr 

Ask the user to check it in incognito/private browser as ServiceNow relies heavily on session cookies. If those aren’t cleared properly, gs.getUser() can behave unpredictably.

Refer: KB0693221 ServiceNow Cookies