Metric-to-CI binding

Release version: Australia

Updated June 16, 2026

2 minutes to read

Summarize

Summarized using AI

Summary of Metric-to-CI binding

Metric-to-CI binding in ServiceNow associates metrics collected by pull connectors with configuration items (CIs) stored in the Configuration Management Database (CMDB). This association enables accurate tracking and analysis of metrics in relation to specific CIs. The platform uses default binding logic for supported connectors, which can be customized if needed.

Show full answer Show less

How Metric-to-CI Binding Works

Metrics are pulled from a vendor by a connector and stored in the metric base (Clotho).
If a metric is unbound, the metric base framework creates an event to request binding.
An event field mapping rule fires on the event, invoking a scripted extension that resolves the appropriate CI.
The CI is recorded in the event’s cmdbci field and the binding is saved in the Metric to CI mappings table.
Subsequent metrics for the same source-resource pair are directly associated with the bound CI without creating new events.
If resolution fails, the metric data remains unbound in the metric base.

Default Behavior for MPN Metrics

For MPN pull connectors, no extra configuration is required. The NokiaMPNMetricCIMapper scripted extension handles binding by checking specific event fields in a prioritized order:

additionalinfo.name matched against the CI class specified in the event
additionalinfo.pmDataSource.dn (distinguished name traversal in cmdbci)
additionalinfo.pmDataSource.serialno matched to serialnumber in cmdbci
additionalinfo.pmDataSource.hwid matched to name in cmdbci
additionalinfo.pmDataSource.nhgalias matched to name in cmdbci

Fields that contain comma-separated values are evaluated from right to left, with the first successful match used to bind the metric. On success, both cmdbci and citype fields on the event are updated.

Customizing Metric-to-CI Binding

If the default binding logic does not fit your CMDB data model, you can override it by implementing your own EventFieldMapping extension point. This customization is applied at runtime based on source and rule names, allowing you to modify binding behavior without changing the product code.

Practical Benefits for ServiceNow Customers

Automatically and accurately link collected metrics to the correct CIs, enhancing data reliability.
Leverage pre-configured logic for common connectors like MPN to simplify setup.
Customize binding rules to align with your unique CMDB structure and naming conventions.
Improve metric analysis, root cause identification, and operational insights by ensuring metrics are correctly associated with infrastructure components.

Metric-to-CI binding associates metrics collected by a pull connector with configuration items (CIs) in the Configuration Management Database (CMDB). Default binding logic is used for each supported connector, which you can override with a custom implementation.

How metric-to-CI binding works

When a metric is collected, the platform runs the following sequence to associate each metric with a CMDB CI:

The connector pulls metric data from the vendor and stores it in the metric base (Clotho).
If the metric is not yet bound to a CI, the metric base framework automatically creates an event to record the request for a binding.
An event field mapping rule fires on the new event. Telecommunications Service Operations Management ships pre-configured event field mapping rules for each supported connector source.
The rule delegates to a scripted extension that resolves the appropriate CI for the event. The script updates the cmdb_ci field on the event with the resolved CI.
The binding appears in the Metric to CI mappings table. From that point on, all subsequent metric data for that source-resource pair is associated with the bound CI directly, without creating another event.

If the scripted extension can't resolve a CI, the event's cmdb_ci field is left empty and the metric data is stored in the metric base unbound.

Default behavior for MPN metrics

No additional configuration is required for CI binding. A scripted extension named NokiaMPNMetricCIMapper handles metric-to-CI binding for the MPN pull connector by firing on matching events through an event field mapping rule.

The extension tries the following event fields in order, stopping at the first match. The first lookup uses the CMDB table named in additional_info.ciClass on the event (defaulting to cmdb_ci); the remaining lookups always run against cmdb_ci:

Table 1. MPN metric event CI lookup order
Order	Event field	Lookup behavior
1	`additional_info.name`	Matched against `name` on the class specified by `additional_info.ciClass`
2	`additional_info.pmDataSource.dn`	Distinguished name traversal in `cmdb_ci`. The deepest matching component wins
3	`additional_info.pmDataSource.serial_no`	Matched against `serial_number` in `cmdb_ci`
4	`additional_info.pmDataSource.hw_id`	Matched against `name` in `cmdb_ci`
5	`additional_info.pmDataSource.nhg_alias`	Matched against `name` in `cmdb_ci`

The additional_info.name and additional_info.pmDataSource.dn fields can each hold a comma-separated list of values. The extension tries the values from right to left, and the first value that resolves to a CI wins.

On a match, the extension sets the cmdb_ci and ci_type fields on the event.

Override the default binding behavior

If the shipped lookup logic does not match how your CMDB models the source data, you can override it by providing your own implementation of the EventFieldMapping extension point. The platform resolves the implementation at runtime by source name and rule name, so you can substitute your own logic without modifying product code.

For the procedure, see Override default metric-to-CI binding.