sys_properties

What It Is

System properties in ServiceNow are persistent key-value configuration pairs stored in the sys_properties table that control platform behavior, feature availability, and application settings without requiring code changes. Unlike generic IT configuration files or registry entries, ServiceNow system properties are database records with built-in versioning, role-based access controls, and update set tracking. Each property consists of a unique name, a string value, an optional description, and metadata that determines its scope and behavior. The platform treats these properties as the authoritative source for runtime configuration decisions, from UI display preferences to complex business rule thresholds.

Architecturally, system properties occupy the configuration layer between the platform's core code and instance-specific customizations. They enable ServiceNow to ship a single codebase that adapts to different organizational needs through property values rather than code branches. This design allows administrators to modify system behavior—enabling features, setting thresholds, configuring integrations—without touching the underlying application logic. Properties can be scoped to specific applications, making them essential for multi-application instances where different teams need isolated configuration spaces. The platform reads these values at runtime through the GlideSystem.getProperty() method, with built-in caching to prevent database hits on every property access.

From a business operations perspective, system properties solve the critical problem of environment consistency and change management in ITSM implementations. Organizations need different configurations for development, test, and production environments, but identical code. Properties enable this separation by allowing the same business rules, workflows, and integrations to behave differently based on property values that travel through update sets or can be set independently per environment. This becomes essential when managing SLA thresholds that differ between business units, integration endpoints that change between environments, or feature flags that control rollout of new functionality to different user groups.

ServiceNow designed properties this way because early enterprise software implementations failed when configuration was hardcoded or scattered across multiple configuration mechanisms. The platform needed a single, auditable, role-controlled method for runtime configuration that could be managed through the same change management processes as code changes. Alternative approaches like configuration files, environment variables, or hardcoded constants all lack the database-driven benefits of transaction safety, role-based access control, and integration with ServiceNow's update set mechanism. The property system also enables ServiceNow's plugin architecture, where each application can define its own property namespace without conflicts.

Different roles interact with system properties in distinct ways that reflect their responsibilities and access levels. Platform administrators create and modify properties to control system-wide behavior, often using them as master switches for features or integration settings. Application developers reference properties in their code to make their customizations configurable rather than hardcoded, treating them as external dependencies that shape application behavior. Process owners and business analysts may never directly manipulate properties but experience their effects through feature availability and system behavior—they're often the requesters of property changes when business requirements shift. End users typically don't interact with properties directly but are affected by them constantly, as properties control everything from UI behavior to notification settings.

Without system properties, ServiceNow would require code modifications for every configuration change, making the platform rigid and change-resistant. Feature toggles wouldn't exist, forcing organizations to accept all functionality or undergo complex customization projects to disable unwanted features. Environment-specific configurations would require separate codebases, destroying the maintainability benefits of the platform. Integration configurations would be hardcoded, making environment promotion nearly impossible. Most critically, the plugin and scoped application system would collapse, as applications couldn't define configurable behavior without risking conflicts with other applications. The property system essentially enables ServiceNow's promise of configurable, upgradeable enterprise software.

Where It Fits in the Platform

System properties sit at the intersection of ServiceNow's data layer and application logic, functioning as the configuration backbone that influences nearly every platform component. They're consumed by business rules, script includes, workflows, and UI policies through server-side JavaScript, making them a dependency for most custom development work. The property system integrates directly with the update set mechanism, allowing configuration changes to be captured, transported, and applied across instances alongside code changes. This positioning makes properties both a development tool and an operational control mechanism.

The property system also serves as a bridge between ServiceNow's application scoping architecture and shared platform resources. Scoped applications can define their own properties without affecting global system behavior, but they can also reference global properties when needed. This creates a hierarchical configuration model where global properties set platform-wide defaults while scoped properties override behavior for specific applications. The caching layer built into property access ensures that this configuration lookup doesn't become a performance bottleneck, even in high-transaction environments.

Key Relationships:

• GlideSystem: The primary interface for accessing property values in server-side scripts through gs.getProperty() and gs.setProperty() methods.
• Business Rules: Frequently reference properties to make threshold values and feature toggles configurable without hardcoding values in the rule logic.
• Script Includes: Use properties for configuration values that need to be shared across multiple scripts while remaining easily modifiable by administrators.
• Update Sets: Properties are automatically captured in update sets when modified, enabling configuration changes to be promoted across environments alongside code changes.
• Domain Separation: Properties can be domain-separated, allowing different organizational units to maintain separate configuration values for the same property names.
• Application Scoping: Scoped applications can define private properties that don't conflict with global or other application properties, enabling modular configuration management.

How You Encounter This in Practice

Integration Endpoint Configuration During Environment Promotion

You're a ServiceNow developer who built a REST integration in your development instance that calls an external API for user validation. The integration works perfectly in dev, but when you promote your update set to test, it fails because the test environment needs to call a different API endpoint. You discover that your integration script includes a hardcoded URL, and changing it requires modifying code in production. During the post-mortem, your architect explains that the endpoint URL should have been stored in a system property from the beginning.

Understanding system properties in this context unlocks the principle of environment-agnostic code—writing integrations that adapt to their environment through configuration rather than code changes. Properties allow the same integration logic to work across all environments while calling environment-appropriate endpoints. Without this knowledge, developers create brittle integrations that break during promotion or require manual code changes in each environment, violating change management policies and creating maintenance overhead.

Business Rule Performance Investigation

You're a platform administrator investigating slow incident creation times reported by users. Performance logs show that a custom business rule on the incident table is taking unusually long to execute, sometimes timing out entirely. Examining the business rule code, you find multiple calls to gs.getProperty() within loops, and the developer has been calling properties that don't exist, causing the system to hit the database repeatedly looking for non-existent property records. The rule was working fine in development with small data volumes but fails under production load.

Understanding properties reveals both the caching behavior that makes them efficient when used correctly and the performance penalties when used poorly. Properties are cached after first access, but non-existent properties still require database queries, and accessing properties inside loops can create performance bottlenecks. This knowledge leads to property access patterns like caching property values in variables at the beginning of scripts and validating property existence before building logic that depends on them.

Feature Flag Rollback During Major Incident

You're an on-call administrator when users report that the new service catalog interface is causing browser crashes for users with older browsers. It's 2 AM, the deployment happened earlier that day, and rolling back the entire update set would take hours and require change approval. Your team lead tells you to disable the new interface by setting a system property value from 'true' to 'false', immediately reverting all users to the previous interface without any downtime or additional approvals.

This scenario demonstrates how properties enable rapid response to production issues through feature flags that can be toggled without code changes or system restarts. Properties provide a safety mechanism that allows teams to deploy new functionality behind flags and disable it instantly if problems arise. Without understanding this capability, administrators might attempt full rollbacks, emergency patches, or other disruptive responses that create more risk than the original problem.

What People Get Wrong

This misconception leads developers to treat properties as static configuration when they're actually dynamic, database-backed entities with complex behaviors around caching, scoping, and access control. Unlike environment variables, system properties can be modified at runtime by users with appropriate roles, are automatically captured in update sets, and can be domain-separated or application-scoped. Properties have a built-in caching layer that affects when changes take effect, and they're subject to the same database transaction and rollback behavior as other ServiceNow records.

This misunderstanding manifests when developers build applications expecting property changes to take effect immediately across all application servers, not realizing that cached values may persist until cache expiration. It also leads to security issues when developers don't consider that properties can be modified by administrators during runtime, potentially changing application behavior in unexpected ways. Teams also miss opportunities to use property scoping effectively, instead creating naming conventions to avoid conflicts when the platform provides built-in isolation mechanisms.

In practice, this misconception causes production issues when teams modify properties expecting immediate global effect but encounter cached values, or when they fail to validate property values in their code because they assume properties are controlled like environment variables. Applications break when administrators modify property values that developers assumed would never change, and integration failures occur when teams don't account for the ServiceNow-specific behaviors around property inheritance and scoping. The most serious consequence is security vulnerabilities when developers store sensitive configuration in properties without understanding the role-based access implications.

This approach ignores the critical importance of property naming conventions, scoping strategies, and lifecycle management that prevent conflicts and maintenance problems in enterprise ServiceNow implementations. ServiceNow has established naming patterns for system properties that indicate their scope, purpose, and ownership, and custom properties should follow similar conventions to avoid conflicts with future platform properties. Properties also need proper documentation, appropriate scoping to applications when relevant, and consideration of how they'll be managed across multiple environments and during platform upgrades.

Developers who create properties without architectural planning often discover conflicts during platform upgrades when ServiceNow introduces new properties with similar names. They also create maintenance nightmares when properties are scattered across global and application scopes without clear ownership models, making it impossible to determine which properties are safe to modify or delete. Poor naming conventions make it difficult for future administrators to understand property purposes, leading to properties that persist long after their original use cases disappear.

The production impact includes failed upgrades when custom properties conflict with new platform properties, system instability when administrators modify or delete mystery properties without understanding their purpose, and security issues when sensitive configuration is stored in globally-accessible properties instead of appropriately scoped ones. Teams also lose the benefits of ServiceNow's application portfolio management when properties aren't properly associated with their owning applications, making it impossible to cleanly remove applications or understand their full configuration footprint.

Admin vs Developer Perspective

For Admins

Admins configure system properties through Application Properties modules or by direct table access to control instance behavior without code deployments. They need to understand that properties inherit from parent scopes and can be overridden at different levels, making troubleshooting configuration issues complex when custom applications introduce their own property definitions. Property changes take effect immediately without restarts, but admins must be careful with boolean values since the platform treats empty strings, 'false', and '0' differently than actual boolean false. Most critically, admins should never delete out-of-box properties even if they seem unused, as they often control undocumented platform behaviors that break unexpectedly.

For Developers

Developers primarily interact with properties through gs.getProperty() in server-side scripts and gs.setProperty() for runtime modifications, always providing default values since properties might not exist in all environments. They should query the sys_properties table directly when building configuration UIs or managing bulk property operations through scripts. Smart developers create property naming conventions within their application scope and document property purposes in the description field since property names alone rarely convey their full impact. The key pattern is treating properties as external configuration that might change between environments rather than hardcoding values that require code updates to modify.

How It Connects to Other Concepts

• **Application Scopes** — properties are scoped to specific applications and inherit through the scope hierarchy, with Global scope properties serving as defaults that scoped applications can override. When you access a property from within a scoped app, the platform first checks for a property in that scope before falling back to Global, making scope-aware property management crucial for multi-app instances.
• **Update Sets** — property changes are automatically captured in update sets when modified through the UI, but properties created or modified through scripts require manual update set handling. Properties with the same name but different scopes are treated as separate records in update sets, which can cause deployment conflicts when moving customizations between instances.
• **Business Rules and Script Includes** — these are the primary consumers of system properties, using gs.getProperty() to make runtime decisions about workflow behavior, integration endpoints, and feature enablement. Property-driven logic allows business rules to adapt without code changes, but creates hidden dependencies that aren't obvious during impact analysis.
• **System Logs** — property access and modification events are logged in various system log tables, with syslog capturing property retrieval failures and sys_audit tracking property value changes when auditing is enabled. These logs become essential for debugging configuration-related issues since property changes can have far-reaching effects across the platform.
• **Client Scripts and UI Policies** — these require alternative approaches since gs.getProperty() isn't available client-side, forcing developers to either pass property values through form fields, use GlideAjax calls, or create UI scripts that embed server-side property values. This server-client boundary makes property-driven UI logic more complex than server-side implementations.
• **REST APIs and Web Services** — integration endpoints are commonly stored as properties to enable environment-specific configurations without hardcoding URLs in scripts. Properties also control authentication tokens, timeout values, and retry logic for outbound integrations, making them central to maintaining different integration behaviors across development, test, and production instances.

Junior vs Senior Knowledge Gap

Junior developers treat system properties as simple key-value storage, missing the critical importance of scope inheritance and property lifecycle management. They'll create properties without considering naming conventions, often duplicating similar properties across different applications or creating overly specific property names that should be parameterized differently. Most juniors don't realize that property access patterns significantly impact performance — calling gs.getProperty() repeatedly in loops or business rules creates unnecessary database hits, and they rarely cache property values appropriately. They also frequently forget that properties are strings by default, leading to bugs when they expect boolean or numeric behavior without explicit type conversion.

The mental model shift happens when developers start thinking about properties as part of the deployment and environment strategy rather than just configuration storage. Senior developers understand that properties create hidden dependencies that aren't captured in dependency maps or impact analysis tools — a seemingly innocent property change can break integrations, alter workflow behavior, or disable features in unexpected ways. They design property hierarchies that support different deployment patterns and always consider how property changes will behave during instance clones, update set deployments, and application installation processes.

Experienced architects know that system properties are often the root cause of "works in dev, breaks in prod" issues because property values differ between environments in subtle ways that aren't obvious during testing. They've learned to audit property dependencies before major deployments and understand that some ServiceNow features have undocumented property dependencies that only surface during edge cases or high-load scenarios. Senior practitioners also recognize that property-driven architecture can become a maintainability nightmare if not properly documented and governed — they've seen instances where critical business logic was controlled by properties that no one remembered creating or understood fully.

The questions that separate senior architects from junior developers revolve around property governance and lifecycle management: How do we ensure property consistency across environments? What's our strategy for deprecating old properties safely? How do we document property relationships and dependencies? Which properties should be environment-specific versus globally consistent? How do we handle property-driven features during application upgrades or instance migrations? These operational concerns rarely appear in basic training but determine whether property-driven architecture helps or hurts long-term platform maintainability.

Quick Reference

• Property names are case-sensitive and limited to 100 characters, but the value field can store up to 4000 characters — longer values get truncated silently without error messages.
• The gs.getProperty() function caches property values per session, so changes made through scripts won't be visible to the same user session until they log out and back in or the cache is explicitly cleared.
• System properties with names starting with glide. are considered platform properties and may be reset during upgrades, while custom properties should use your application's scope prefix.
• Empty string, 'false', 'False', 'FALSE', 'f', 'F', '0', and 'no' are all treated as falsy by gs.getProperty() when used in boolean contexts, but null/undefined properties return your default value instead.
• The sys_properties table has a unique index on name + sys_scope, allowing the same property name to exist in multiple scopes but preventing duplicates within a single scope.
• Properties marked as private=true are excluded from clone operations and instance exports, making them useful for environment-specific secrets or configurations that shouldn't propagate.
• The platform loads system properties at startup and caches them aggressively — property changes through direct database modification may not take effect until the next restart or cache flush.
• Properties can be marked as ignore_cache=true to force database reads on every access, but this severely impacts performance and should only be used for properties that change frequently.
• ServiceNow has over 2000 built-in system properties controlling everything from UI behavior to integration timeouts — modifying these without understanding their full impact can break core platform functionality.
• The suffix field enables property arrays — properties with the same name but different suffixes (like my.prop.0, my.prop.1) can be retrieved as arrays using gs.getProperties().