CMDB and Auto-Number fields


The Auto-Number Platform Feature

Record Numbering is a way of automatically numbering records with a unique number and prefix. This is most commonly seen with Task tables, where the Number field is a string make up of a prefix and number specific to the task class. e.g. INT00012324 or CASE0100024, for incident or case tables which extend the task table. New records get the next number in the sequence. These share the 'number' field defined on the task table. The sys_number and sys_number_counter tables define the prefix, and keep track of the count. The getNextNumber...  methods populate the default value in new records.

There is a platform limit of 1 auto-number field per table, which also means 1 Prefix per table. For Extended Tables like the CMDB, 'Table' means 'Class', so for sets of tables in an Extended Table hierarchy it is possible to have different fields/prefixes for tables in different branches.

Extending/child classes will inherit the field and Prefix from the parent table, unless overridden by a different Prefix defined on the child table/class. For example, Business Service [cmdb_ci_service] has prefix "BSN", but Monitored Service [cmdb_ci_service_auto]  which extends it has prefix "SNSVC". If a customer has added a custom field at a high level, perhaps on cmdb_ci class, then that field's numbering and prefix will be overridden by the out-of-box fields for the branches of the hierarchy where those are defined.

When creating a number field, it will only be possible "If an auto-numbered field does not already exist..", and an error popup may appear if one does. The problem with this checking code is that it cannot predict what plugins might be installed in future, or that future changes in the base platform might add or change number fields, and only then would the custom field become an invalid and unsupportable customisation, that may break something.

Out-of-the-box Fields in the CMDB

In the case of the CMDB, the opportunity for a number field in relation to service CIs was first taken early in the history of ServiceNow. The "Service Portfolio Management" plugin certainly had a number field on Business Service table [cmdb_ci_service] in Jakarta, which may have been moved there from an earlier field on the child Service Offering [service_offering] table, although the history is unclear.

The "Application Portfolio management" plugin added a number field on Business Application [cmdb_ci_business_app] with prefix APM in Istanbul, and in Orlando that was moved into the core CMDB plugin which is present in all instances, so all customers have had that since Orlando. 

The Common Service Data Model (CSDM), which has the important purpose of standardising data for Service CIs for all apps using the platform, has inherited the Business Service number field for backwards compatibility, and migrated the field up the extended table hierarchy/tree to the Business Service [cmdb_ci_service] table, to cover all Service CI classes in that branch. This is labelled Service ID in the instance. In Paris, prefixes for this field were added for the Business Service [cmdb_ci_service] and Monitored Service [cmdb_ci_service_auto] tables. Business rules to enforce unique numbering have been added.

Other Number fields have been added to CMDB-related tables, that are not part of the main CMDB extended table as well, Such as Outage and Tasks related to CMDB health/audit remediation.

As of the Paris version, the out-of-box fields, tables and prefixes in the CMDB are:

APMBusiness Application [cmdb_ci_business_app]cmdb_ci_business_app.number
BSNBusiness Service [cmdb_ci_service]
Plus extending tables:
SLA Configuration [em_sla_configuration]
Technical Service [cmdb_ci_service_technical]
Service Offering [service_offering]
Service Group [cmdb_ci_service_group]
SNSVCMonitored Service [cmdb_ci_service_auto]
Plus extending tables:
Application Service [cmdb_ci_service_discovered]
Technical Service [cmdb_ci_query_based_service]
Manual Service [cmdb_ci_service_manual]
Alert Group [cmdb_ci_alert_group]

Standalone CMDB tables, not part of the main CMDB CI extended table hierarchy:

OUTOutage [cmdb_ci_outage]cmdb_ci_outage.number

CMDB Task tables:

DUPRemediate Duplicate Task [reconcile_duplicate_task]task.number
ORPHOrphan CI Remediation [orphan_ci_remediation]
RECDRecommended Field Remediation [recommended_field_remediation]
RECOMPCMDB Multisource Recompute Task [cmdb_multisource_recomp_task]
REQDRequired Field Remediation [required_field_remediation]
STALStale CI Remediation [stale_ci_remediation]
TASK*Follow On Task [cert_follow_on_task]

*Follow On Task [cert_follow_on_task] records created by CMDB Remediation rules for CMDB Audit results inherit the "TASK" prefix and numbering from the parent task table. There is currently no specific prefix and numbering for Follow On Tasks, and and so the numbering will not be sequential due to Task [task] table records, and other task extended tables without their own prefixes also incrementing the count.

Additional Information

Potential problems caused by these fields: