Naming patterns in inventory templates

  • Release version: Australia
  • Updated June 16, 2026
  • 2 minutes to read
  • Summarize
    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 Naming patterns in inventory templates

    Naming patterns in inventory templates use JavaScript expressions to define how configuration items (CIs) are named when created from inventory templates. This feature ensures vendor-compliant, consistent naming for network interfaces and slots, which is critical for operational workflows such as alarm correlation, fault management, and device configuration.

    Show full answer Show less

    Where naming patterns apply

    Naming patterns can be defined in two key places:

    • On equipment models: Models provide default naming patterns for slots and interfaces, serving as the baseline for all templates created from that model.
    • On related templates within an inventory template: Each slot, sub-slot, or interface template can override the model’s default naming pattern. If no pattern is specified, the inventory model’s name is used as a fallback during CI creation.

    The Inventory Template Overview tab displays these fallback names as tree node labels, reflecting the names the CIs will carry once created.

    What a naming pattern looks like

    Each naming pattern is a JavaScript expression returning a string. Patterns can combine variables, literal text, string methods, and conditional logic to generate names. For example:

    • Simple pattern: "Slot -"+position produces names like Slot -1.
    • Complex pattern: parentslotname.replace("Slot-","Slot/").replace("Slot/","Ge")+" (" + (position < 2 ? "Tx" : "Rx") + ")" produces names like Ge6/1 (Tx).

    Variables are resolved from the related template's context. Unresolvable variables display as ? in the Overview tree to highlight gaps before creating CIs.

    When naming patterns are evaluated

    Naming patterns are evaluated at two points:

    • Template definition time: When viewing the Inventory Template Overview tab, the system previews resolved names for all patterns without creating any CIs.
    • CI creation time: When an inventory template is used to create CIs in the CMDB, the pre-evaluated names are applied to the new CIs.

    After CIs exist, any naming pattern changes require manual updates to both the CI records and the templates.

    Practical benefits for ServiceNow customers

    • Ensures consistent and vendor-compliant naming across network inventory items, improving accuracy and operational efficiency.
    • Allows previewing and validation of naming conventions before CI creation, preventing errors and minimizing post-creation fixes.
    • Supports customization by enabling overrides at the template level for fine-tuned naming control.

    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-compliant names for network interfaces and slots within inventory templates.The Naming Patterns feature generates vendor-compliant names for network interfaces and slots within inventory templates. Telecom operators can define naming conventions that align with vendor-specific formats, ensuring 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 that is 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 on a related template starts as a copy of the model's default and can be edited to override the default on a per-template basis.

    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 so that you see the same name that the CI will carry once 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 — for example, a top-level slot has no parent slot and therefore no parent_slot_name — are substituted with ? in the Inventory Template Overview tree so that you can identify the gap before the template is used to create CIs.

    Naming patterns are evaluation

    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 you the 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 agent must manually 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 so that names are correct before any CIs are created. Without this verification, errors in patterns surface only after CIs exist in the CMDB.