Contents

What field normalization does

SAVE AS PDF

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.