| NowSpectrum | Issue #6 · Weekly Tips |
Hey {{first_name}}, 👋
This week — three GlideSystem (gs.) methods that show up in almost every ServiceNow script, and the one mistake that makes each of them unreliable.
Why this matters —
GlideSystem is the most-used API in ServiceNow scripting after GlideRecord. Most developers know what these methods do. Fewer know exactly when they return unreliable results.
1. gs.getUserID()
Returns the sys_id of the currently logged-in user. Works perfectly in Business Rules and Client Scripts triggered by a real user session.
var currentUser = gs.getUserID(); // In a Scheduled Job: returns "system" or empty gr.setValue('updated_by', currentUser); // ✕ wrong attribution
Scheduled Jobs run with no logged-in user. gs.getUserID() returns the system user or an empty string — not the person who configured the job.
2. gs.isInteractive()
Returns true if the script is running because a real user is interacting with the UI — false during imports, scheduled jobs, and background processing.
if (!gs.isInteractive()) { // ✓ skip notification logic during bulk import return; }
This is the standard guard clause for Business Rules that should fire on real user edits but not on bulk Transform Map updates — prevents 10,000 import rows from triggering 10,000 emails.
3. gs.getProperty()
Reads a System Property value. Simple, reliable — but only if you handle the case where the property doesn't exist yet.
var retries = gs.getProperty('x_myapp.max_retries', '3'); // ✓ '3' is the fallback if the property was never created
Without a second argument, a missing property returns an empty string — not null, not an error. Scripts that do math on the result (parseInt('')) get NaN silently.
| The full GlideSystem reference — every gs. method, with real examples — is on nowspectrum.com | Read full article → |
— The NowSpectrum Team
| NowSpectrum | nowspectrum.com |