CMDB and Auto-Number fieldsSummaryThe 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: PrefixTableFieldAPMBusiness Application [cmdb_ci_business_app]cmdb_ci_business_app.numberBSNApplication Service (previously Business Service) [cmdb_ci_service]Plus extending tables:SLA Configuration [em_sla_configuration]Dynamic CI Group (previously Technical Service) [cmdb_ci_service_technical]Service Offering [service_offering]Service Group [cmdb_ci_service_group]cmdb_ci_service.numberSNSVCMonitored 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.numberORPHOrphan 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.Related LinksPotential problems caused by these fields: It is possible for customers to make customisations without hitting the 1 field per table limit at the time, before installing plugins or upgrading to versions that add number fields. That will lead to issues such as the count incrementing by more than one each time a new record is inserted, or number sequence or prefixes being overridden in some branches of the CMDB hierarchy.The OOTB code should not be customised so please don't attempt to revert those OOTB field additions or changes. The solution in these cases would be to implement a similar custom auto-numbering and prefix system, independent of the OOTB one. A new script would be used for the default value instead of the getNextNumber... method. That script might hard-code the prefix, and use a custom table record for keeping track of the current count, specific to the additional field.The Community Idea Portal has the following idea: Allow more than 1 Auto Number field per table. If you would find having multiple number fields on the same table, each with their own prefix and counters, then please consider Up-voting and leaving a comment with your business requirement on that Idea form. PRB1456249 has been created to track cases where customer already had a number field. Please link support cases to that:KB0966591 The auto-number prefixes added in Paris for Service CIs as part of the CSDM changes cause issues with number fields due to the one field per table limitationThere are several fields named 'number' in different branches of the CMDB using auto-numbering, which can cause confusion because these are not the same columns in the underlying SQL table, even though they have the same names.Since Paris, business rule "Check Uniqueness for SN App Service ID" and "Check service name uniqueness" run on insert/update for any Business Service [cmdb_ci_service] and extending table CIs. This can abort the insert or update if another CI already exists with the number value, or the same name. These errors will appear on screen: Invalid insert. Service with SN App Service ID: BSN0001008 already exists. Invalid update The count in the sys_number_counter record may be out of sync with the values already in records. Manually edit the sys_number_counter record for the prefix to be 1 more than is currently in the number fields of service CIs. Business service Big Splash US Central already exists. Please enter a different name. Invalid update This is expected behaviour. You must have unique service names from Paris. If you are copying a service, change the name before selecting Insert & Stay.Do you have several records with duplicate numbers already?The field is not set Unique in the Dictionary, and should not be, and so this situation is allowed by the underlying SQL database point of view There could be many causes: Were records pre-existing before upgrading to Paris, which was when the Business Rules were added?Have the Business Rules been disabled?Were records imported from another instance, that that had independently created records on a different counter?Did clone settings mean records were copied from a source instance and the existing records of the target instance were also preserved?...and I'm sure there are more potential causes. Check record created times against the upgrade history and current counters. Clicking the New button in a filtered list automatically applies the same filter to the new record. For example, clicking New on a CMDB list, where a specific CI number was filtered on, opens a record preset with Number set to the existing record the list was matching on. This overrides the default value of the field set in the dictionary, which must be the case for this feature to be used, but that also means the next number that would be populated on the form using a scripted default value, which is how autonumber is implemented, is also overridden. To change this behaviour so that filter breadcrumb functionality is not applied for the specific field, add dictionary attribute: ignore_filter_on_new=trueSee: Filters and breadcrumbs (Rome docs)This dictionary attribute was changed OOTB for the main service tables cmdb_ci_service and cmdb_ci_business_app in Quebec, to avoid the list filters overwriting the next number (PRB1431792).