What It Does

The gs.getProperty() method queries the sys_properties table for a record where the name field matches your key parameter. It returns the value field as a string, regardless of what type of data the property actually contains. This is ServiceNow's primary mechanism for storing and retrieving configuration values that should be adjustable without code changes.

Internally, ServiceNow caches property values in memory after the first access, making subsequent calls to the same property very fast. The platform reads from the database only when the property hasn't been cached yet or when the cache is invalidated. This caching behavior means property changes don't take effect immediately in running sessions.

The method always returns a string data type, even if the property value looks like a number or boolean. If the property doesn't exist and you didn't provide a defaultValue, it returns null. If the property exists but has an empty value field, it returns an empty string.

Property names are case-sensitive and must match exactly what's stored in the sys_properties table. The platform includes hundreds of built-in properties with names following dot notation conventions like glide.servlet.max_filename_length or email.smtp.port. You can also create custom properties for your applications.

This method is closely related to gs.setProperty() for writing property values and gs.getPropertyValue() which attempts to convert the string result to the appropriate JavaScript data type. Most developers use getProperty() and handle type conversion manually for better control.

When to Use This

Use gs.getProperty() whenever you need configurable values that administrators should be able to modify without touching code. This includes timeout values, API endpoints, feature flags, maximum record counts, email addresses for notifications, and any other setting that might need to change between environments or over time. System properties provide a clean separation between configuration and business logic.

Don't use this method for data that belongs in regular tables or for values that should be stored per-user or per-record. System properties are instance-wide settings. If you need user preferences, use the User Preference API. If you need application-specific configuration with more complex data structures, consider creating a dedicated configuration table instead of cramming everything into system properties.

Avoid using gs.getProperty() in loops or frequently-called functions without caching the result locally. While the platform caches properties, every call still has overhead. Store the result in a variable if you'll use it multiple times within the same script execution.

Return Value

The method always returns a string when the property exists, even if the stored value looks like a number, boolean, or other data type. If you need the value as a specific type, you must convert it yourself using parseInt(), parseFloat(), or boolean comparison. When the property doesn't exist, the method returns either null or your provided defaultValue.

Always check for null returns when you don't provide a default value, especially in production code. The safest pattern is to always provide a sensible default value as the second parameter. This prevents null reference errors and makes your code's behavior predictable even when properties are missing or misconfigured.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Platform Behavior & Side Effects

  • No Business Rules, ACLs, or notifications fire when reading properties — this is a direct database read with caching
  • Property values are cached in memory after first access, making subsequent calls very fast but changes don't appear immediately
  • No database writes occur — this method is read-only and safe to call in any script context
  • Performance is excellent after caching, but first access requires a database query — consider caching results locally in loops
  • Works identically in Business Rules, Script Includes, Scheduled Jobs, and UI Actions — no behavioral differences based on context
  • Property access is not logged in system logs unless the property itself controls logging behavior
  • Scoped applications can only access properties they own or global properties — cross-scope property access is restricted