What Are System Properties?
Every ServiceNow instance is controlled, in a major way, by System Properties.
This is a table that is behind the scenes, and when modified, can completely change the UI/UX or configuration of a ServiceNow instance.
But with great power, comes great responsibility, and this area is to be modified, only once you have a solid respect and grasp for it.
NOTE: When updating system properties, you must know what you’re doing. Never create system properties directly in production, and always test your properties. Never delete properties if you’re unsure of what they do.
Let’s dive into what they are, how to update them and even, how to create and reference your own in scripting.
Understanding System Properties
Below, you’ve got a list view of the system properties in an OOB instance of ServiceNow.
Okay, so there are these properties in the system, but what do they really do?
Let’s dive into what they are exactly, from an admin or developers perspective.
In ServiceNow, system properties are variables that control the behavior and functionality of the platform. These properties can be set at the global level, which means that the value applies to the entire instance, or at the application level, which means that the value only applies to a specific application or module within the instance.
This is what all system properties are locked down, to just admin users.
There are many different types of system properties, including:
- General properties: These properties control various aspects of the platform, such as the default language and time zone, the maximum number of records that can be returned in a single query, and the maximum size of attachments that can be uploaded.
- Email properties: These properties control how the platform handles email, including the email server settings and the email address that the platform uses to send messages.
- LDAP properties: These properties control the integration of the platform with an LDAP (Lightweight Directory Access Protocol) server, which is used to manage user authentication and authorization.
- Notification properties: These properties control how the platform handles notifications, such as email notifications and in-app notifications.
- Performance properties: These properties control various aspects of the platform’s performance, such as the maximum number of threads that can be used by the platform and the maximum size of the cache.
System properties can be accessed and modified through the System Properties module in the ServiceNow platform.
Admins control these properties, to change different settings and behaviors in their instance.
So as you can see, they essentially are responsible for everything in the system.
They should really only be modified, with the direct super vision of ServiceNow engineering support.
Making changes to properties without knowing what you’re doing, can have huge and negative impacts to your instance.
Create Your Own System Property
So there are thousands of system properties in every ServiceNow instance.
But did you know that you can actually create your own and then reference them in scripts?
All you need to do is go to sys_properties.list, click enter, and create a new record.
Let’s go ahead and create a new property called “RandomProperty”.
Now that the property is created, I’ll go ahead and access it with a server side script.
You do this with the following syntax:
gs.print(gs.getProperty("RandomProperty"));
When you run this in a background script, you will get the following:
*** Script: hereIsMyValue
So you can create custom values, that can be accessed from any server-side script.
It’s a great place to throw values that you’ll need to reference repeatedly, and when you don’t want to hardcode a value.
Say you’ve got a value that you need to reference a bunch in a script. You can just store it in a system property, and then reference it in the script. If it changes, you can just change the system property value, as opposed to going through your script and replacing every single occurance of the value.
Let’s talk about these custom system properties a bit more.
Custom system properties are user-defined variables that can be created and used to store values that are specific to an organization or to a particular application or module. These properties can be used to store configuration values, settings, or other information that is specific to the organization or application.
There are several reasons why a ServiceNow developer might create a custom system property:
- To store values that are specific to the organization or application: Custom system properties can be used to store values that are specific to the organization or application, such as API keys, URLs, or other configuration values.
- To allow users to customize the platform: Custom system properties can be used to allow users to customize the platform by setting values for various options or preferences. For example, a custom system property could be used to allow users to choose the default language for the platform.
- To enable or disable certain features: Custom system properties can be used to enable or disable certain features of the platform. For example, a custom system property could be used to turn on or off a particular module or feature.
- To store data that needs to be shared across multiple applications or modules: Custom system properties can be used to store data that needs to be shared across multiple applications or modules within the platform. This can be useful for storing values that are needed by multiple applications or modules, such as API keys or shared configuration values.
So there are OOB and custom properties.
You can reference any of them in a script, if you need to continually refer to a value.
If there’s something that your company does regarding system properties, we’d love to know.
