---
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
---
# Create CI types for Service Mapping and Discovery
# Create CI types for Service Mapping
and Discovery {#ariaid-title1}
* Release version: Australia
*
* Updated March 12, 2026
*
*  7 minutes to read
Create CI types
(or CI classes) for applications and devices, which Service Mapping and Discovery do not support by
default.
## Before you begin
Role required: service_mapping_admin, personalize_dictionary, or admin
Verify that there is no
existing CI type for this application or device.
## About this task
All applications and hosts in your organization must have a corresponding configuration item (CI) type, which is necessary for discovering and processing applications and hosts correctly.
Note:
The Discovery and the CMDB interface refers to CI types as CI classes.
A wide range of preconfigured CI types that cover most commonly used applications are
available to you. If your organization uses a less known or proprietary application
that does not have a corresponding CI type, you must create it.
A CI type is a generic notion that is used by several ServiceNow applications, but
there are some attributes that are specific to Service Mapping and Discovery.
A CI type (or class) contains several important definitions that apply to all CIs belonging to it, such as:
* CI attributes are added as fields to the CMDB tables.{#t_CreateCITypeForSM__conref_CIattribCMDBtables}
{#t_CreateCITypeForSM__conref_CIattribCMDBtables}
* Identifiers help Service Mapping and Discovery to differentiate between new and existing CIs. For example, if there is an Apache Web Server CI type defined in the CMDB, and Service Mapping and Discovery both discover an Apache Web Server CI, it processes it using identifiers. It then recognizes it as an updated version of the Apache Web Server CI that already exists in the system, not a new Apache Web Server CI.{#t_CreateCITypeForSM__conref_SpecialAttrIdentif}
* There are [reconciliation rules](https://www.servicenow.com/docs/access?context=r_ReconciliationRulesPrinciples&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US) that help the ServiceNow platform to consolidate CI attributes received from different applications correctly. These rules are necessary for organizations where more than one application participates in the discovery process. Reconciliation rules define how attributes of the same CI discovered by different discovery sources are merged. For example, Service Mapping discovers the version and home directory attributes of an Apache Web Server CI, while Discovery discovers the version and patch level attributes for the same Apache Web Server CI. The ServiceNow AI Platform applies the reconciliation rule and as a result Service Mapping does not overwrite the attributes found by Discovery.{#t_CreateCITypeForSM__conref_ReconcilicationRules}
{#t_CreateCITypeForSM__conref_ReconcilicationRules}
* Related items, both CIs and non-CIs, serve as a reference and provide additional information about the CI. For example, you can define a serial number, a port and an network APR table as related items for a hardware server. The system does not use these items for identification. After you configure related items for the CI type, you can use horizontal discovery for CIs of this type together with their related items. For information, see [Discover related items together with the main CI](https://www.servicenow.com/docs/AM9CWkIU_fwg9wW0qXrJoA "Add related items to the patterns to perform horizontal discovery of configuration items with all their related items: CIs or non-CIs, like ports or serial numbers.").
Note:
Non-CIs are items that do not extend the Configuration Item \[cmdb_ci\] table. Examples of non-CIs are ports, serial numbers, or Network ARP tables.
* CMDB stores CI class in the form of a hierarchy where some CI classes are parents to other CI classes, who automatically derive their parent's attributes in addition to attributes you configure specifically for child CI classes. CI class hierarchy is used widely for configuring CI behavior, relationships, and display. In this example, the Apache Web Server CI is a child of the Web Server CI and derives many attributes from its parent, such as name, version, model ID. By default, child CI classes inherit identifiers from their parent CI classes.
{#t_CreateCITypeForSM__ul_lml_fdx_st}
In addition to these CI type definitions, the horizontal discovery process uses a CI
classification to define to which CI type a CI belongs. Create a device CI
classification if you create a CI type for devices using SNMP and a process CI
classification for an application CI type.
## Procedure
1. Navigate to AllConfigurationCI Class Manager.
2. To use an existing CI type as a parent for the new CI type, select Hierarchy to display the CI Classes list.
3. Select the context menu for the required CI type and select Add Child Class.
4. [Create a table](https://www.servicenow.com/docs/access?context=t_CreateATable&version=australia&pubname=australia-platform-administration&ft:locale=en-US) to store the CI type attributes:
{#t_CreateCITypeForSM__table_fcb_myv_dt__entry__2}
| Field | Description |
|-|-|
| Label | CI type name. For example, Apache Web Server. |
| Name | The table name. For example, cmdb_ci_apache_web_server. Use a name similar to the other CMDB classes (for example, u_cmdb_ci_laptop). |
| Extends table | The table name of the parent CI type. All CI types are extensions of the Configuration Item \[cmdb_ci\] table or its child tables. For example, if the new class is Laptops, which is a subclass of Computers, select the cmdb_ci_computer table. If the new class is a top-level class, select the cmdb_ci table. The most commonly used parent CI types are: * cmdb_ci - basic * cmdb_ci_database - for databases * cmdb_ci_app_server - for application servers * cmdb_ci_infra_service - for infrastructure services * cmdb_ci_endpoint_inclusion - for entry points of the inclusion type * cmdb_ci_appl - for applications * cmdb_ci_web_server - for web servers * cmdb_ci_lb - for load balancers * cmdb_ci_endpoint - for entry points {#t_CreateCITypeForSM__ul_xcc_wbs_2t} |
[Table 1. Table form fields]
{#t_CreateCITypeForSM__table_fcb_myv_dt}
5. Configure how the instance determines if a discovered CI is an upgraded CI existing in the instance or a brand new CI.
See [Create or edit a CI identification rule](https://www.servicenow.com/docs/access?context=t_CreateCIIdentificationRule&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US) for detailed procedure.
Warning:
If there is no CI identification rule for a CI type, Service Mapping discovers CIs belonging to this type, but cannot interpret the results of the discovery process. In this case, the ServiceNow AI Platform rejects the discovery results for these CIs and their information is not updated.
1. On the Identifiers page, configure the parameters as follows:
{#t_CreateCITypeForSM__table_p4p_ycs_2t__entry__2}
| Field | Description |
|-|-|
| Name | Use a meaningful name. |
| Applies to | Enter the CI type. |
| Active | Select the check box. |
| Independent | Clear the check box. |
[Table 2. Identifier form]
{#t_CreateCITypeForSM__table_p4p_ycs_2t}
2. Configure the identifier entry parameters as follows:
{#t_CreateCITypeForSM__table_ccz_1yx_2t__entry__2}
| Field | Description |
|-|-|
| Criterion attributes | Select the attribute that you want to use for identifying the CI. For example, Class, Installation directory, or Serial number. |
| Allow null attribute | Select the check box. |
| Priority | If there is more than one identifier entry, add priority to determine the order in which Service Mapping applies these entries. If none of the identification criteria matches the discovered CI, this CI is new. |
[Table 3. Identifier entry form]
{#t_CreateCITypeForSM__table_ccz_1yx_2t}
{#t_CreateCITypeForSM__substeps_omx_jxx_2t} {#t_CreateCITypeForSM__conref_identificationRuleStep}
{#t_CreateCITypeForSM__conref_identificationRuleStep}
6. **Optional:** Configure references to other CIs or non-CIs as related items for the CI type.
{#t_CreateCITypeForSM__table_jdn_c2j_m3b__entry__2}
| Field | Description |
|-|-|
| Active | Check box that specifies that the related entry is active. |
| Related table | A related table that references the CI that is being matched. |
| Referenced field | A referenced field in Related table that should store the referenced CI. This field always references the cmdb_ci table, or a descendent of the cmdb_ci table. |
| Priority | Priority of the related entry for the specified Related table. Rules with lower priority numbers are given higher priority while matching a related item for specific related table. Related entries for the specified related table with identical priorities are applied randomly. You can keep gaps between the priority numbers, so you can assign the unused priority numbers to new entries without modifying the existing priority order. |
| Criterion attributes | The set of attributes to uniquely identify the related item. Attributes can belong to the current class, or to a parent class. Note: It is possible to add reference fields as a criterion attribute. However, such fields might not always be effective: * Reference fields store sys_ids that point to a record in another table, and thus is considered a weak criterion attribute (in terms of uniqueness) for the current table. * The system detects and then replaces invalid values in a reference field with 'Unknown'. For example, an invalid Model ID value is replaced with the value 'Unknown'. Also, if several CIs end up having that same reference field set to 'Unknown', then these CIs become duplicate CIs. {#t_CreateCITypeForSM__ul_p3k_xgs_3rb} Select the lock icon to view, add, or remove attributes from the identification rule. |
| Allow null attribute | If at least one criterion attribute in the related table is not null, allow to attempt matching with an identifier entry even if there are criterion attributes which are null. |
| Filter conditions | Add conditions to construct a filter to narrow the set of records that will be searched for a matching related item. |
[Table 4. Related Entry form]
{#t_CreateCITypeForSM__table_jdn_c2j_m3b} {#t_CreateCITypeForSM__configure-ci-related-items}
{#t_CreateCITypeForSM__configure-ci-related-items}
7. **Optional:** Configure the instance to consolidate CI attributes received from different data sources correctly.
See [Create or edit a CI reconciliation rule](https://www.servicenow.com/docs/access?context=create-reconciliation-rule&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US).
Configure the
following Service Mapping related parameters correctly:
{#t_CreateCITypeForSM__table_h3w_1fy_2t__entry__2}
| Field | Description |
|-|-|
| Data source | Select ServiceWatch. |
| Applies to | Select the relevant CI type. |
| Optional condition | Set a condition if necessary. |
[Table 5. Reconciliation Definition form]
{#t_CreateCITypeForSM__table_h3w_1fy_2t}
Note:
If you do not create a CI reconciliation rule, data discovered by patterns is used to update CI attributes.
8. Configure the CI classification for your CI type:
* For CI types representing applications, perform configuration as described in [Create a Discovery process classification](https://www.servicenow.com/docs/Ut8zP2rAy4sKKvicIuwaCg "A process classification allows Discovery to create a particular CI type from information gathered during the identification and exploration phases.").
* For CI types representing SNMP devices, perform configuration as described in [Create a Discovery CI classification](https://www.servicenow.com/docs/SSxAivg8J_Y2~NZ4Nyyziw "A CI classification allows Discovery to discover most common operating systems, network devices, and processes.").
{#t_CreateCITypeForSM__choices_opw_kwf_tw}
Note:
There is no need to create CI classifications for hosts because these classifications are included in the base system.
9. For CI types that represent inclusions, define the hierarchy for the new CI type.
Clear the Reverse Relationship Direction check box while performing this configuration.
See [Create dependent relationships](https://www.servicenow.com/docs/access?context=create-dependent-relationship&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US).
10. If necessary, customize icons that represent CIs in maps.
See [Create or modify map
icons](https://www.servicenow.com/docs/access?context=t_CreateModifyNGBSMMapIcons&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US).
**Previous topic:** [Password2 encryption for patterns](https://www.servicenow.com/docs/h2Pqj64MX20O1frqYYENRg "The Password (two-way encrypted) field type is used to encrypt and decrypt data. The field type works in accordance with NIST 800-57 guidelines and provides FIPS 140-2-L3 protection.")
**Next topic:** [Create entry point types for Service Mapping](https://www.servicenow.com/docs/zPrBGSiMWZVf06hJ_MQO~A "An entry point is a point where clients access a service instance. Service Mapping starts the mapping process for every application service from the entry point you define for it. Service Mapping includes a wide range of preconfigured entry point types that cover most commonly used applications. If your organization uses a less known or proprietary application that does not have a corresponding entry point type in Service Mapping, you must create it.")
*[\>]: and then