---
sourceDocument: Australia IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-operations-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Automatic CI field population

# Automatic CI field population {#ariaid-title1}

* Release version: Australia
* 
* Updated August 11, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Automatic CI field population

Automatic CI field population in Discovery allows ServiceNow customers to set configuration item (CI) field values dynamically during the discovery process using generic attributes.
These attributes follow a scope hierarchy---schedule, range set, and IP address range---enabling granular control over how CI fields like location and asset tags are populated.
This eliminates the need for multiple Discovery schedules for different locations or groups and reduces manual updates post-discovery.
Show full answer Show less  

## Key Features

* **Scoped Attribute Hierarchy:** Attributes can be defined at the schedule level (broadest), range set level, or IP address range level (most granular). Discovery applies the most specific attribute available for each discovered CI.
* **Target Table Filtering:** Attributes can be targeted to specific CMDB CI classes or applied broadly to all CIs by selecting the base Configuration Item \[cmdbci\] table. More specific CI classes take precedence.
* **Field Value Types:** Supports reference values (linking to records in other tables, e.g., Location) and static string values (e.g., custom asset tags).
* **Hierarchical Overrides:** More granular attributes override broader ones, allowing precise customization---e.g., a schedule-level location can be overridden by a range set or IP address range attribute.

## Practical Application

By configuring generic attributes at various scope levels, customers can:

* Automatically assign accurate location, asset tag, and other CI fields during discovery without creating separate schedules.
* Ensure discovered CIs inherit the most relevant field values based on their IP address or network segment.
* Reduce manual CI corrections and improve CMDB data quality and consistency.

## Example Scenario

Consider a Discovery schedule with a range set and two IP addresses:

* Schedule level attribute sets Location = Maryland (applies to all CIs).
* Range set attribute sets Location = Baltimore for Linux Servers.
* IP address 10.0.0.52 attribute sets Location = 123 Main St, Baltimore.
* IP address 10.0.0.117 attribute sets Asset tag = tag-test.

Result: The CI at 10.0.0.52 gets the most specific location (123 Main St, Baltimore). The CI at 10.0.0.117 inherits Baltimore as its location from the range set and gets its asset tag set to "tag-test."  
Discovery generic attributes can automatically set configuration item (CI) field values during discovery. Attributes follow a scope hierarchy, where more specific scopes override broader ones, enabling you to
define defaults at the schedule level and apply precise values at the range level.

## Benefits {#ci-field-disco-attributes__section_z3v_lgf_k3c}

Using generic attributes to populate CI fields provides the following benefits:

* Eliminate the need to create separate Discovery schedules for each location or group of CIs that require different field values.
* Set CI field values at the schedule, range set, or IP address range level, providing precise control over location data, asset tags, and other fields.
* Reduce manual CI updates after discovery by automatically populating fields during the discovery process.
* Use the attribute hierarchy to define broad defaults at the schedule level and override them with more specific values at the range set or range level as needed.
{#ci-field-disco-attributes__ul_ajs_4gf_k3c}

## How it works {#ci-field-disco-attributes__section_w2v_qgf_k3c}

Previously, CI field values such as location could only be set globally on a Discovery schedule. This meant that all CIs discovered within a schedule inherited the same value, even when more specific information was available for individual IP addresses or range sets.

Generic attributes solve this problem by enabling you to define field values at multiple levels of granularity. When discovery runs, it evaluates the attributes defined at each scope level and applies the most granular
matching attribute to each discovered CI.

## Scope levels {#ci-field-disco-attributes__section_h4g_sgf_k3c}

You can define generic attributes to populate CI fields at the following scope levels. Each level represents a different degree of granularity.{#ci-field-disco-attributes__table_c2f_tgf_k3c__entry__2}

| Scope | Description |
|-|-|
| Schedule | Applies the attribute value to all CIs discovered within the entire schedule. |
| Range set | Applies the attribute value to all CIs discovered within a specific range set associated with the schedule. |
| Range | Applies the attribute value to all CIs discovered within a specific IP network, IP address range, or IP address list. |
[ ]

{#ci-field-disco-attributes__table_c2f_tgf_k3c}

## Attribute hierarchy {#ci-field-disco-attributes__section_tth_vgf_k3c}

When attributes are defined at multiple levels, Discovery applies the most granular value to the resulting metadata, which can influence both CMDB field population and Discovery runtime behavior. The scope hierarchy from least to most granular is: schedule, range set, IP address range. A range-level attribute overrides a range set-level attribute, which overrides an IP
network-level attribute, and so on. Additionally, attributes can target specific CMDB CI classes. When attributes with the same key exist for different classes within the same class hierarchy, the more specific class takes
precedence. If no attribute is defined at a more granular scope or specific class, the CI inherits the value from the next available level.

For example, set the Location field to Maryland at the schedule level, Baltimore at the range set level, and a specific street address at the range level. A CI discovered from an IP address in that
range inherits the street address. A CI discovered from a different IP address in the same range set inherits Baltimore, because no range-level location is defined.

## Field value types {#ci-field-disco-attributes__section_c3y_xgf_k3c}

Discovery generic attributes support two types of field values.{#ci-field-disco-attributes__table_dk5_1hf_k3c__entry__2}

| Type | Description |
|-|-|
| Reference | A value that references a record in another table. For example, the Location field references a record in the Location \[cmn_location\] table. |
| Static | A string value that you enter directly. For example, you can set the Asset tag field to a custom string value. |
[ ]

{#ci-field-disco-attributes__table_dk5_1hf_k3c}

## Target table filtering {#ci-field-disco-attributes__section_mxg_chf_k3c}

Each attribute includes a Target Table field that specifies which CI class the attribute applies to. You can set the target table to the base Configuration Item \[cmdb_ci\] table to apply the attribute to all discovered CIs. To
restrict the attribute to a specific class and its child classes, select a more specific class, such as Linux Server \[cmdb_ci_linux_server\].

## Example {#ci-field-disco-attributes__section_lbg_2hf_k3c}

The following example illustrates how the attribute hierarchy works across three scope levels.  
A Discovery schedule contains a range set with two IP address ranges. You define the following attributes:

* **Schedule level: Location** = Maryland (applies to all CIs in the schedule)
* **Range set level: Location** = Baltimore (target table: Linux Server)
* **IP address (10.0.0.52): Location** = 123 Main St, Baltimore
* **IP address (10.0.0.117): Asset tag** = tag-test (static value)
{#ci-field-disco-attributes__ul_c4q_ghf_k3c}  
After discovery runs:

* The CI discovered at 10.0.0.52 has its **Location** field set to **123 Main St, Baltimore** because the range-level attribute is the most granular.
* The CI discovered at 10.0.0.117 has its **Asset tag** field set to **tag-test** . Because no range-level **Location** attribute is defined for this IP, the CI inherits **Baltimore** from the range set-level attribute.
{#ci-field-disco-attributes__ul_nyn_3hf_k3c}