Working with System Properties

https://www.servicenowguru.com/system-definition/working-with-system-properties/

uch of the behavior of a ServiceNow instance is controlled by System Properties. System properties are a great way to add options to your system and keep people (including yourself) from having to make modifications to back-end code later on. Business rules, UI actions, and UI pages rely pretty heavily on system properties just for this purpose. If I’ve ever got variable values that should be available system-wide then my first thought is to put that value in a system property that can be changed in the UI and be referenced from multiple places in the future. Chances are you’ve worked with these properties as part of your system setup. It’s always a good idea to be aware of the different properties in the system and what they do. The ServiceNow wiki contains a listing of system properties with their descriptions that you can review.
The purpose of this post is to show the different ways you can access, display, and work with properties in the system UI and in the ServiceNow scripting environment.

Creating or Editing a Property

Most of the system properties can be found in your left navigation under the ‘System Properties’ application as shown above. ALL of the properties in the system are stored in the ‘sys_properties’ table and can be viewed and edited there by typing ‘sys_properties.list’ into the left navigation filter.
You can add a property to your system simply by creating a new record in the ‘sys_properties’ table as shown in the wiki.

Adding your property to a properties page

It’s great to be able to modify properties from the properties table, but it’s a lot more convenient to make the edit through a properties page. Properties pages are what you get when you click on a module under the ‘System Properties’ application in the left navigation of your ServiceNow instance.
Properties pages are really just a URL that pulls together one or more System Property Categories into a single UI page to be viewed. You can create or modify these categories by navigating to ‘System Properties->Categories’. Here’s what one of the properties categories looks like for the Email settings out-of-box…

As you can see, there’s really not a whole lot to it. Simply give the category a name (which will be referenced in your page URL), a title (which will be displayed as a section header), and add your properties to the related list at the bottom of the page.

Accessing a properties page

A properties category in and of itself doesn’t do anything for you though. In order for these to be displayed as part of a page you need to create a module that points to the correct URL to include the categories and present them all on one page. This is exactly how the email properties page works. Here’s the module URL…

https://demo.service-now.com/system_properties_ui.do?sysparm_title=Email%20Properties&sysparm_category=Email,POP3,Email%20Security,Email%20Auto%20User,Email%20Advanced

And here’s what that page looks like…

A system properties page URL needs to have 3 different parts…

1. A pointer to the properties UI page (https://demo.service-now.com/system_properties_ui.do)

2. A ‘sysparm_title’ parameter to add a title to your page (sysparm_title=Email%20Properties)

3. A ‘sysparm_category’ parameter to indicate which properties categories should be included in the page (sysparm_category=Email,POP3,Email%20Security,Email%20Auto%20User,Email%20Advanced)

So this example points you to a properties page with a title of ‘Email Properties’ that includes 5 properties categories – ‘Email’, ‘POP3’, ‘Email Security’, ‘Email Auto User’, and ‘Email Advanced’. One thing that I noticed as I tested this is that the ‘%20’ escaping for the spaces in the URL is necessary for this to work properly.

Either way you choose to display your properties, you’ll need to access them in script for them to be of any real use. Here’s how you can do that…

Accessing a property in server-side script (Business Rules, UI Actions, UI Pages, etc.)

//Return the value of the ‘your.property.name.here’ system property
var propertyValue = gs.getProperty('your.property.name.here');

Accessing a property in client-side script (Client Scripts, UI Policies, etc.)

There isn’t a way to directly access a system property in client script and the need to do this is probably extremely rare. If you do have a situation where you need to access a system property in client script you can do so in a few ways.

1. Add the property to your session client data as shown here.

The nice thing about this method is that you don’t have to do an expensive GlideRecord query to get your property information. It gets added to the client session data when the session is established for a particular user.

2. Add the property to the ‘g_scratchpad’ object using a ‘Display’ business rule as shown here.

This option is similar to the previous one, but doesn’t set the property for the entire session…just for the table you’re working on.

3. Create a GlideRecord Query and pull from the ‘sys_properties’ table.

While this method is probably the most familiar to you and seems the simplest, it can also be a huge performance killer. Because of this, this method should only be used if no other method is readily available. Any time you’re going to perform a client-side GlideRecord query, I highly recommend setting your script up to run that query asynchronously as described here.
You can query for a system property like this…

var rec 
= 
new GlideRecord
('sys_properties');
rec.
addQuery('name', 
'your.property.name.here');
rec.
query();
if(rec.
next()){
var yourPropertyValue 
= rec.
value;
}