Inventory template naming patterns
Summarize
Summary of Inventory template naming patterns
Inventory template naming patterns in ServiceNow use JavaScript expressions to define how configuration items (CIs) are named when created from inventory templates. This feature enables telecom operators and other users to generate vendor-conforming, consistent names for network interfaces, slots, and other physical or logical network resources. Accurate naming is crucial for operational workflows such as alarm correlation, fault management, and device configuration.
Show less
Where Naming Patterns Apply
Naming patterns can be defined at two levels:
- Equipment model: Provides default naming patterns for slots and interfaces, serving as the base for all templates created from the model.
- Related templates within inventory templates: Slots, sub-slots, or interfaces can override model defaults with their own naming patterns. If no pattern is defined, the system uses the inventory model name when instantiating CIs.
The Inventory Template Overview tab displays fallback names and resolved names for related templates, matching the actual CI names after creation.
Structure and Evaluation of Naming Patterns
Naming patterns are JavaScript expressions that return strings and can combine:
- Literal text and variables resolved at evaluation time
- String methods
- Conditional logic
Variables come from the related template context; unresolved variables appear as ? in the Inventory Template Overview tree to help identify missing references before CI creation.
When Naming Patterns Are Evaluated
- Template definition time: Opening the Inventory Template Overview tab evaluates all patterns and shows resolved names as tree node labels without creating any CIs. This provides a preview and validation of names.
- CI creation time: When an inventory template is instantiated, the resolved names are applied to the newly created CIs in the CMDB.
If naming patterns are modified after CIs exist, administrators must update names on both the CI records and the templates to ensure consistency.
Inventory Template Hierarchy and Validation
The Inventory Template Overview tab displays the full template hierarchy, allowing customers to verify and validate all resolved CI names before deployment. Name pattern validation occurs:
- At save time to prevent syntax or logic errors
- When loading the Overview tab to catch relationship-specific issues
Administrators can extend validation by registering custom rules via an extension point to enforce organization-specific naming conventions beyond the default checks.
Key Benefits for ServiceNow Customers
- Ensures consistent, vendor-conforming CI names aligned with operational standards
- Enables early detection and correction of naming errors before CIs are created
- Supports flexible customization at model and template levels for naming conventions
- Facilitates improved network inventory management and integration with operational workflows
A naming pattern is a JavaScript expression that defines how a CI (configuration item) is named when it is created from an inventory template.
The naming patterns feature generates vendor-conforming names for network interfaces and slots within inventory templates. Telecom operators can define naming conventions that align with vendor-specific formats to maintain consistency across the network inventory. Accurate names for physical and logical network resources are essential for operational workflows such as alarm correlation, fault management, and device configuration.
Where naming patterns apply
A naming pattern can be defined in two places:
- On an equipment model. A model carries default naming patterns for the slots and interfaces it contains. The model pattern acts as the default for every template created based on that model.
- On a related template within an inventory template. Each related template — a slot, sub-slot, or interface — carries its own naming pattern. The pattern starts as a copy of the model default and can be edited to override it for each template.
A related template that does not define a naming pattern, such as a card or module template, falls back to the inventory model name at instantiation. In the Inventory Template Overview tab, this fallback name appears as the tree node label. The label matches the name the CI carries after it is created.
What a naming pattern looks like
A naming pattern is a JavaScript expression that returns a string. The expression can reference variables that the system resolves at evaluation time, combine literal text with those variables, apply string methods, and use conditional logic.
A simple pattern concatenates a literal and a variable:
"Slot -"+position
For a related template at position 1, this pattern resolves to Slot -1.
A more complex pattern can use string methods and a ternary conditional:
parent_slot_name.replace("Slot-","Slot/").replace("Slot/","Ge")+" (\" + (position <2 ? \"Tx\" : \"Rx\") + \")\"
For an interface at position 1 whose parent slot is named Slot-6/1, this pattern resolves to Ge6/1 (Tx).
Variables that the pattern references are read from the related template's context. Variables that cannot be resolved at design time are substituted with ? in the Inventory Template Overview tree. For example, a
top-level slot has no parent_slot_name. The tree displays ? so you can identify the gap before using the template to create CIs.
When naming patterns are evaluated
Naming patterns are evaluated at two distinct times:
-
At template definition time, when you open the Inventory Template Overview tab on an inventory template. The Overview evaluates every pattern in the template's hierarchy and displays the resolved name as each tree node's label. No CIs are created at template definition time. The Overview tab provides a preview.
-
When an inventory template is used to create CIs in the CMDB, the names that were resolved at design time are applied to the new CIs. If a naming pattern changes after CIs exist, an administrator must update the name on both the CI record and the template.
The Inventory Template Overview tab lets you verify naming end to end at design time, before any CIs are created. Without this verification, errors in patterns surface only after CIs exist in the CMDB.