Demystifying glide.servlet.uri in ServiceNow

[Anish Reghu]

When you're building robust, URL-aware scripts or integrations in ServiceNow, one of the most frequently used dynamic properties is:

gs.getProperty('glide.servlet.uri');

At first glance, it seems simple — it gives you the base URL of your instance. But peek under the hood, and you'll find it's not listed in the sys_properties table, yet it works perfectly. So where does it come from? How is it computed? And what happens if you try to override it?

In this blog, we'll unpack every layer of how glide.servlet.uri behaves, how it's computed, and when to use (or not use) it.

---

What Is glide.servlet.uri?

• It’s a dynamic system property that returns the base URL of your ServiceNow instance, typically in the format:

  https://<instance>.service-now.com/
  

• Commonly used to construct full URLs in:

  • Scripted Notifications

  • REST responses

  • Email templates

  • External system redirects

---

❓ But Why Doesn’t It Show Up in sys_properties?

Because it's not stored in the database at all. When you do:

gs.getProperty('glide.servlet.uri');

ServiceNow:

1. First looks in the sys_properties cache.

2. If not found, checks if it's a special dynamic property.

3. For glide.servlet.uri, ServiceNow then calculates the value at runtime using the internal servlet context.

---

🔍 How Is glide.servlet.uri Calculated?

Internally, ServiceNow uses Java servlet APIs wrapped inside Glide classes like GlideSystem, GlideRequestContext, and GlideServletRequest to build the URL.

Here’s what the logic roughly looks like under the hood:

String scheme = request.getScheme();         // "https"
String serverName = request.getServerName(); // "dev12345.service-now.com"
int port = request.getServerPort();          // 443
String path = request.getContextPath();      // usually "/"

String url = scheme + "://" + serverName;
if (!isDefaultPort(scheme, port)) {
    url += ":" + port;
}
url += path;

Reference for HTTPServletRequest - here.

✅ Default Ports Are Hidden

To keep URLs clean:

• https://example.com:443 becomes → https://example.com

• http://example.com:80 becomes → http://example.com

• Only non-default ports (like 8443, 8080) are included.

---

📊 Visualizing the Resolution Flow

🧪 When Does It Fail?

Since the URI is computed from incoming request context, it doesn’t work reliably in:

• Scheduled Jobs

• Background Scripts without active user session

• Notifications triggered outside a web request

• MID Server scripts

In such cases, ServiceNow may:

• Return a blank value

• Or a previously cached URI (which is unreliable)

---

🔧 Can I Override It in sys_properties?

Yes — but you shouldn't unless you're absolutely sure.

❗What Happens If You Create glide.servlet.uri in sys_properties?

• It takes precedence over the computed value.

• Your hardcoded value is used in all server-side calls to gs.getProperty('glide.servlet.uri').

• Dynamic resolution is completely bypassed.

⚠️ Risks of Overriding:

Risk	Impact
🔁 Breaks portability	If the instance is cloned or domain name changes
❓ Misleading behavior	Developers may think it’s dynamic when it’s not
🧪 Fails context-based routing	For integrations that rely on correct servlet port or host
📧 Incorrect URLs in notifications	If overridden incorrectly

📌 Best Practice: Instead of overriding it, define your own property like x_yourscope.base_url and reference that in scripts.

---

💡 When Should You Manually Define It?

• For scheduled jobs, offline scripts, or MID Server integrations where there's no active HTTP context.

• In such cases, having a manually defined fallback is safer.

Example:

var url = gs.getProperty('glide.servlet.uri') || gs.getProperty('x_myapp.base_url');

---

Final Thoughts

The glide.servlet.uri property is a clever internal feature of ServiceNow that dynamically derives your instance base URL when needed — without being explicitly stored in your property table.

But with great power comes great responsibility:

• Don’t override it unless absolutely necessary

• Understand how it’s resolved

• Know when it may not return the expected value

• Use fallback strategies in background or headless contexts.

Regards,

Anish Reghu

(Please Hit Like, if you find this useful)