--- sourceDocument: Australia ServiceNow AI Platform Administration sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/platform-administration Release : - australia ft:locale : - en-US ft:publication_title : - Australia ServiceNow AI Platform Administration ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # Normal values # Normal values {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Normal values Normal values in ServiceNow provide a standardized way to consolidate multiple similar but ambiguous field values into a single, consistent value. This is essential when data originates from diverse sources such as automated Discovery inputs, imports from external systems, or manual user entries, which can create numerous variations of the same logical field value. Show full answer Show less ## Field Value Variations and Challenges Variations in field values, like different representations of a CPU Type (e.g., "E3350 (Intel) 4.5.2234," "Intel Xeon 5.4.554," "L3350"), can cause issues such as: * Duplicate records for essentially the same value * Poor search results * Complex queries and business logic conditions Implementing a normal value record standardizes these into one canonical value (e.g., "Xeon"), improving data quality and simplifying operations. ## Key Features ### Aliases Aliases are predefined known variants of the input value that map directly to the normal value. They are best for cases with a limited number of known variants. When a normalization job or query detects an alias, it automatically substitutes it with the normal value. Aliases function similarly to rules using simple equality conditions. ### Rules Rules define conditions---often using regular expressions or complex logic---to identify a broad or dynamic set of variant values and normalize them. They are processed after aliases and are suitable when variant values are numerous or complex. Aliases and rules can be combined to achieve comprehensive normalization. It is important to test normalization logic thoroughly before applying it globally to existing database records. ### Normalized Queries Administrators can enable normalization on queries against normalized fields by selecting the "Normalize query" option. This ensures that filters and queries operate against the normalized values, enhancing search accuracy. While the actual filtering uses normalized values, filter breadcrumbs display the original raw query terms for clarity. ### Scripting and Normalization Scripts that insert or update records automatically apply normalization to field values. For example, a script inserting a CI with a CPU type "Xeon L3350" will normalize it to "Xeon" on insert. Additionally, queries that test for equality or inequality on normalized fields can be configured to return normalized values instead of raw ones, ensuring consistency in scripted operations. ## Practical Benefits for ServiceNow Customers * Eliminates confusion caused by multiple variants of the same field value * Improves the accuracy and reliability of searches, reports, and business rules * Simplifies scripting and query logic by working with consistent normalized values * Enhances data quality and reduces duplicate records A normal value replaces similar but ambiguous field values with one standard value. ## Field value variations {#c_WhatFieldNormalizationDoes__section_qkk_3jw_x1b} Records values can come from multiple sources such as: * Automated entries made by Discovery. * Automated entries made by importing records from external systems or files. * Manual entries made by users. {#c_WhatFieldNormalizationDoes__ul_vgd_k21_x1b}Each of these sources may describe the same field value in several different forms. For example, the CPU Type field on a computer CI form might display any of the following similar values: * E3350 (Intel) 4.5.2234 * Intel Xeon 5.4.554 * Xeon L3350 * L3350 {#c_WhatFieldNormalizationDoes__ul_q4v_5kz_xp} Without normalization, these variant field values results in: * Duplicate CPU types * Poor search results * Complex queries and conditions to apply business logic {#c_WhatFieldNormalizationDoes__ul_srv_q3w_x1b} Creating a normal value record solves these issues by consolidating on one standard value such as Xeon. ## Identifying variations with aliases and rules Each Normal value record specifies how to identify variations of a normal value using a combination of aliases and rules. Aliases : Aliases are known variations of an input value that normalization converts to the normal value. Use aliases when there is a short list of variant values. For example, you could create a normal value Xeon that has these aliases. * E3350 (Intel) 4.5.2234 * Intel Xeon 5.4.554 * Xeon L3350 * L3350 {#c_WhatFieldNormalizationDoes__ul_jjc_2w1_x1b} Whenever a normalization data job or normalized query sees a field value matching an alias, it automatically replaces the field value with the normal value. Normalization data jobs and queries process aliases before rules. Note: Aliases are logically equivalent to rules using the \[is\] operator in a condition where \[Field name\]\[is\]\[Alias value\]. For example, the sample aliases are equivalent to these rules: \[CPU Type\]\[is\]\[E3350 (Intel) 4.5.2234\] OR \[CPU Type\]\[is\]\[Intel Xeon 5.4.554\] OR \[CPU Type\]\[is\]\[Xeon L3350\] OR \[CPU Type\]\[is\]\[L3350\] Rules : Rules specify the conditions under which normalization replaces an input value with the normal value. Use rules when there are a large number of possible variant values, or when you must create complex conditions. For example, the normal value Xeon could have this rule. \[CPU Type\]\[matches regex\]\[.\*\\bxeon\\b.\*\] Whenever a normalization data job or normalized query sees a field value matching a rule, it automatically replaces the field value with the normal value. Normalization data jobs and queries process rules after aliases. Rules and aliases can be combined to normalize a field. Make sure to test your normalization methods before applying them to all the existing records in the database. ## 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, [Filters and breadcrumbs](https://www.servicenow.com/docs/access?context=c_UsingFiltersAndBreadcrumbs&version=australia&pubname=australia-platform-user-interface&ft:locale=en-US) using the original (raw) value for the normalized field in the query condition. 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. ## Scripting and normalization {#c_WhatFieldNormalizationDoes__section_cmg_5wp_x1b} Scripts that update 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. **Related topics** * [GlideRecord](https://www.servicenow.com/docs/access?context=p_GlideServerAPIs&version=australia&pubname=australia-api-reference§ion=c_GlideRecord&ft:locale=en-US)