What are System Properties?
System properties in ServiceNow control thousands of specific options regarding the behavior and configuration of the platform.
This is incredibly far ranging, but it includes modifying the color scheme, how long it takes for users to be automatically logged out, time zone formatting, various logging levels, and even custom options. There are approximately ~2,000 Base System properties in ServiceNow, pending the software family version your instance is running on.
Once you understand the power of system properties, you will beging to use them more and have a different and improved understanding of the ServiceNow Platform.
It is also worth mentioning that each ServiceNow instance comes with most of, but NOT all of the system properties that exist. Say you’re referencing a ServiceNow Community article, or you’re speaking to Technical Support in HI and they reference a property, and you don’t see it – that may simply be because your instance doesn’t have the property created.
A handful of system properties in ServiceNow are modified once, usually during the implementation of the platform and are then essentially left alone. Be sure to make any changes to system properties in a Sub Production instance and have a good reason for updating values. System Properties modify behavior globally in the system, so again – use caution when updating them. The vast majority of System Properties are never updated and just control how the system behaves.
At this point, it is completely safe to create the System Property as a new property if you can properly define it’s type and possible values.
How To View Your System Properties
Like many behaviors in ServiceNow, there are a few different ways to do this. Here are the most common ways.
1) To view ALL system properties, simple go directly to the table.
You can go to a table directly in the Application Navigator, or you can modify the URL – both get you to the same place.
Via the Application Navigator, type sys_properties.list and hit enter. This will bring up the entire table. It’s also worth mentioning that you can view the records of any table this way.
You type in the table name (not the display name) and then place either, .list, .form or .FORM at the end of it. Play around with each of these options and see what happens. Moving on.
Via the URL, update your URL to follow this format:
https://INSTANCE_NAME.service-now.com/sys_properties_list.do
You can also use the ServiceNow Modules under the System Properties application. They break down different system properties into sections that have a different UI than just the list view of a table.
Custom System Properties
Why would someone want to use a custom system property?
The benefit of referencing a system property is that is defined just once, but you can reference it multiple times and from anywhere.
For example, say you’re building out an integration and the endpoint of the other environment is needed to be referenced a ton within a single script.
Instead of defining the variable and referencing it, or even worse, continuing to just write the API endpoint down, you can just create a system property – and reference it each time the script there. Here is the major benefit of doing this. Say this endpoint is being changed/updated for whatever reason. If this is the case, you take a few seconds and update the system property value. As opposed to reviewing all of your scripts, and trying to find all occurrences of where you reference it.
How Do You Reference a System Property in a Script?
To access the value of a system property, use the following syntax:
gs.getProperty(“name_of_property”);
We will show you how to test this momentarily.
Keep in mind, this is a server side operation, so it can only be done in a Business Rule, a Processing Script on a UI Page or a Script Include. If you absolutely must reference a system property in a client side script, consider either using GlideAjax to retreive the data, or just store in in a variable on the client.
So, you would next create a New record on the sytem property table, giving it a unique name. Out of box – you can’t create duplicate entries with the same name, this should be kept as is and not be modified.
For this example, we will store and later reference the name of this Blog.
Once you save the record, you’ve created a custom system property.
Now we mentioned earlier that you could reference this anywhere on the server, globally.
So the fastest way to test this out would be to attempt to print out the value in a Background – Script.
Create a background script of the following and see what it prints out.
If you hit “Run Script”, you should see the following on the results page:
At this point, the value that is in the referenced system property should be printed on the Results page. Run this in the ‘global’ scope.
If you get any errors, take a look at the system property again and make sure everything is spelled correctly.
Now you can obviously extend this to any of the existing system properties and their values. So whether you want to reference an existing value or even create a custom one of your own – you can do so and get the value back with one line of code.
