---
sourceDocument: Australia Telecommunications Network Inventory
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/telecom-network-inventory

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Telecommunications Network Inventory

ft:clusterId :

    - telninv

bundleId :

    - telninv

workflow :

    - Customer and Industry


---

# Inventory template naming patterns

# Inventory template naming patterns {#ariaid-title1}

Release version: Australia  
Updated November 5, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Inventory template naming patterns

Inventory template naming patterns in ServiceNow Australia release enable telecom operators to define JavaScript-based naming conventions for configuration items (CIs) created from inventory templates.
These patterns ensure vendor-conforming, consistent names for network interfaces and slots, which are crucial for operational workflows such as alarm correlation, fault management, and device configuration.
Show full answer Show less  

## Where naming patterns apply

* **On equipment models:** Models provide default naming patterns for slots and interfaces, acting as the baseline for all templates derived from that model.
* **On related templates within inventory templates:** Slots, sub-slots, or interfaces have naming patterns initially copied from the model but can be customized per template. Related templates without naming patterns default to the model name at CI creation.

## How naming patterns work

Naming patterns are JavaScript expressions that produce string names by combining literal text, variables, string methods, and conditional logic. Variables are evaluated in the context of the related template, with unresolved variables shown as "?" in the Inventory Template Overview tree to highlight gaps before CI creation.

## When naming patterns are evaluated

* **Template definition time:** The Inventory Template Overview tab evaluates and previews all naming patterns in the template hierarchy, displaying the resolved names as tree node labels without creating CIs.
* **CI creation time:** When an inventory template is instantiated, these resolved names are applied to the newly created CIs in the CMDB.
* **Name updates:** If naming patterns change after CIs exist, administrators must manually update both CI records and templates to maintain consistency.

## Inventory Template Overview and validation

* The Overview tab displays the full template hierarchy with resolved CI names, enabling verification and error detection before deployment.
* Name pattern validation runs both at save time and when loading the Overview tab to prevent errors and check template relationship-specific issues.
* Administrators can implement custom validation rules through an extension point to enforce organization-specific naming conventions beyond default checks.

## Practical benefits for customers

By leveraging inventory template naming patterns, ServiceNow customers can:

* Ensure consistent, vendor-aligned naming of network resources to support operational efficiency.
* Preview and validate naming conventions before deploying inventory templates, reducing post-deployment errors.
* Customize naming patterns at model or template levels to meet specific organizational or vendor requirements.
* Maintain naming integrity across the CMDB by managing updates systematically when patterns change.  
A naming pattern is a JavaScript expression that defines how a configuration item (CI) 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 {#naming-patterns-in-inventory-templates__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, defaults 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 {#naming-patterns-in-inventory-templates__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 can't 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-in-inventory-templates__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 enables you to 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.
* **[Model and template naming](https://www.servicenow.com/docs/ZPkPs1KenjM8EmkrF~5xSQ)**   
  The equipment model establishes default naming patterns for CIs (configuration items). Inventory templates inherit those patterns and can override them per related template.
* **[Inventory template name generation](https://www.servicenow.com/docs/CCrLEtlGESzt1X5cp~lJ6Q)**   
  When you instantiate an inventory template, each related template in the hierarchy produces a CI (configuration item). The CI's name comes from one of two sources, depending on whether the related template defines a naming pattern.
* **[Inventory template hierarchy view](https://www.servicenow.com/docs/OS5FfXQqJRLARW~lpc5gSw)**   
  The Overview tab on an inventory template record shows the full template hierarchy as a tree. Use it to check resolved CI names and spot validation errors before deploying the template.
* **[Name pattern validation](https://www.servicenow.com/docs/F3MseOUzi5mOeZu7IW4e_A)**   
  Name pattern validation runs twice. It runs at save time to prevent errors. And it runs when the Overview tab loads the hierarchy to catch issues specific to template relationships.
* **[Extension point for custom name validation](https://www.servicenow.com/docs/s4l5gViXtJg0QWdr8s9Utw)**   
  The custom name validation extension point validates resolved names in the Inventory Template Overview tab. Administrators can register custom validation rules to enforce organization-specific naming conventions, replacing or extending the default check.

**Related concepts**   

* [Model and template naming](https://www.servicenow.com/docs/ZPkPs1KenjM8EmkrF~5xSQ "The equipment model establishes default naming patterns for CIs (configuration items). Inventory templates inherit those patterns and can override them per related template.")
* [Inventory template name generation](https://www.servicenow.com/docs/CCrLEtlGESzt1X5cp~lJ6Q "When you instantiate an inventory template, each related template in the hierarchy produces a CI (configuration item). The CI's name comes from one of two sources, depending on whether the related template defines a naming pattern.")
* [Inventory template hierarchy view](https://www.servicenow.com/docs/OS5FfXQqJRLARW~lpc5gSw "The Overview tab on an inventory template record shows the full template hierarchy as a tree. Use it to check resolved CI names and spot validation errors before deploying the template.")
* [Name pattern validation](https://www.servicenow.com/docs/F3MseOUzi5mOeZu7IW4e_A "Name pattern validation runs twice. It runs at save time to prevent errors. And it runs when the Overview tab loads the hierarchy to catch issues specific to template relationships.")