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

SeijiNscr · 3 weeks ago

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.

GlideFather · 3 weeks ago

Hi @SeijiNscr,

check with that user if they are sure about the correct number.

Otherwise this is default value what you share and perhaps there is some onChange script that overrides it. The best approach would be to connect with that person to show you in a live session to check it immediately.

It is a default value so it shall be enough to load the form, or an admin can impersonate for that user yourself, no?

_____
100 % GlideFather experience and 0 % generative AI

SeijiNscr · 3 weeks ago

Hi @GlideFather

Thank you for the suggestion.

I had the user send me a screenshot, and the phone number shown was indeed different from their own.
However, when I impersonated the user on my side and tested the catalog item, I was not able to reproduce the issue — the correct phone number appeared every time.
So the issue definitely occurred on the user’s side, but I still don’t know what caused it, especially since it didn’t happen again after clearing the instance cache.
This unpredictable behavior makes me a bit concerned about potential recurrence.
If it happens again, I will try to troubleshoot it immediately in a live session as you recommended.

GlideFather · 3 weeks ago

@SeijiNscr and when you check the actual phone number in the record associated with that user on the sys_user table?

_____
100 % GlideFather experience and 0 % generative AI

SeijiNscr · 3 weeks ago

Hi @GlideFather
Yes, I checked the user’s record in the sys_user table.
The phone field for the user who reported the issue was actually NULL.
Because of that, no phone number should have been displayed for them at all.
This is exactly why the issue was noticed — despite the sys_user.phone value being NULL, a completely different user’s phone number was shown on the catalog item.