Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.
  • Madrid
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store

What field normalization does

Log in to subscribe to topics and get notified when content changes.

What field normalization does

Records for things like devices and companies are brought into the ServiceNow platform by manual entry, imports, and Discovery.

Depending on how it is introduced into the database, a field value might appear in several different forms. For example, the CPU Type field on a computer CI form might display any of the following names for the same type of CPU, depending on the source of the entry:
  • Xeon L3350 or L3350 (manual entry)
  • Intel Xeon 5.4.554 (created by Discovery)
  • E3350 (Intel) 4.5.2234 (imported value)
The lack of a normalized CPU type field in this example could result in duplicate CMDB records for each variation in the field value. Different CPU types also present a problem for reporting. To report accurately on all computers that use a Xeon processor, an administrator must know all the possible permutations of the name and construct a very complex query. To prevent these issues, an administrator can normalize the original values using one of two methods:
  • Aliases: Aliases map all the variations of the name manually to one normal value. Use aliases for short lists of name variants. During processing, the platform looks here first when determining how to normalize a field. If no aliases are defined, the platform searches for rules that apply.
  • Rules: Write a rule to associate large numbers of variant names to a normalized value automatically by using standard operators, such as begins with, starts with, or contains. Rules and aliases can be combined to normalize a field. Make sure to test your rules before applying them to all the existing records in the database.

In our example, aliases are sufficient for converting the possible variations of the Intel Xeon CPU type into one, normalized value, such as Xeon. When a recognized variant is entered in a field, the platform automatically replaces the variant with the normalized value. If properly configured, field normalization also affects the search results from a filter in a record list. In our example, an entry of L3350 in a filter returns a list of Xeon CPUs, if that variation of CPU type was normalized.

Scripting and normalization

Scripts that update records or insert records into the database (GlideRecord) are normalized automatically when field normalization is applied. For example, if a script to insert a CI record contains a CPU type of Xeon L3350, the script is normalized to insert the CI with a CPU type of Xeon instead. Scripts that query the database for normalized field values (using the conditions of equals or not equals) can be configured to return the normal value (such as Xeon) rather than the original (raw) value.

Normalized queries

An administrator can configure normalization to apply to queries issued against normalized fields in lists. Select the Normalize query check box on the Normalization form to enable this functionality. In a list containing normalized values, create a filter using the original (raw) value for the normalized field in the query condition.

Figure 1. Normalized query example

The filtered list returns records with the normal value substituted for the raw value. However, the breadcrumbs for the filter display the original query conditions.

Figure 2. Normalized query results