Best Practice 1: Use system properties instead of hard-coded values.

When required values are hard-coded into the server-side scripts, changes to these values must be manually adjusted in every script where they appear. To save time and maintenance, create system properties with scripts using the values contained in those properties. When a system change is required, changes made to a single system property can be implemented system-wide.

Best Practice 2: Define and use a naming convention.

Define and use a naming convention that makes the property easy to manage. This allows users to filter custom properties from the hundreds in the system properties list.

To define a property:

1. Create a property name with the company name.
2. Add the application or process name (or both) using a dot notation to separate the elements.
3. Add a description that is short and meaningful. If the property refers to a script, include the script name. For example, cd.default.assignment_group.
4. To create system properties for the values:
• Enter sys_properties.list in the Navigation filter.
• Check for an existing property with the needed functionality before creating a new one.
• Click New.
• In the Name field, enter cd.default.assignment_group (for example).
• In the Description field, enter the default assignment group description.
• From the Type choice list, select string.
• In the Value field, enter the corresponding value for the default assignment group.
• Click Submit.

Best Practice 3: Group properties into categories.

To create a category to group properties:

1. Navigate to System Properties > Categories.
2. Click New.
3. In the Name field, enter the new category.
4. In the Description field, enter the category description.
5. Right-click the form header and select Save.The properties-related list is now displayed.
6. Click Edit.
7. Select the properties and Add them to the new category.

Best Practice 4: Create a Properties page to display properties.

The Properties page gives easy access to all of the properties in one place. To display properties, create a new module under the appropriate application menu.

1. Right-click the application and select Edit Application Menu.
2. In the modules-related list, click New.
3. For Title, enter Properties.
4. For Link type, select URL (from Arguments).
5. For Roles, select admin.
6. For Order, use the number where this should appear on the application menu.
7. Click the image icon.
8. Select the Properties icon.
9. For Arguments, use the system properties UI page.
10. Click Submit. The property page now appears in the application menu.

Warning: System properties store configuration information that rarely or never changes. Each time you change or add a system property, the system flushes the cache to keep all nodes in the cluster in synch. This cache flush might cause temporary performance issues to the instance if done excessively. As an alternative to a system property to store configuration information that changes more than once or twice a month, you can use instead a custom table to store regularly changing configuration information.

Best Practice 5: Business Rules

The When field on the Business Rule form indicates whether the Business Rule script runs before or after the current object is saved to the database. The most commonly used Business Rules are before and after rules.

You can use an async Business Rule in place of an after-Business Rule. Async Business Rules are similar to after rules in that they run after the database commits a change. Unlike after rules, async rules run in the background simultaneously with other processes. Async Business Rules allow ServiceNow to return control to the user sooner but may take longer to update related objects.

Follow these guidelines to determine which value to choose for the When field.