The Purpose of this Article (what’s in the article and what’s not)
- What this covers: The concept and usage of TNI Attribute Packs. When to use packs versus custom columns on OOB tables, practical examples and implementer tips to keep models clean and upgrade-safe.
- What this does not cover: Point-and-click configuration steps.
- Audience: TNI implementers, network architects, CMDB administrators.
Extension: Overview of Available Options
It’s common for network resources to need extra attributes across technologies and use cases. The ServiceNow platform, CMDB, and TNI support two primary patterns for adding custom attributes, and both are upgrade-safe.
These patterns are:
- TNI Attribute Packs (TNI-specific) - create and assign them to selected CIs. TNI Attribute Packs avoid changing the CI table schema by storing the extra attributes in a separate pack table (extend Pack Base sn_attribute_pack_base), configure the pack against the target CI class using Pack Config with filter conditions, and then add the pack on the CI record.
- Add custom columns on OOB tables and add/extend CMDB tables as needed (inherent to the CMDB) - custom columns change the class schema but are created with the u_ prefix and persist across upgrades.
Applied Examples:
This article recommends which method to use when and provides examples related to the design of an L3VPN service using the three-layer architecture of Network Service Instance class CIs (cmdb_ci_network_service_instance), which play the following roles:
- IPVPN_MGMT_Service NSI - Represents the customer-facing L3VPN service (the global service layer).
- VRF NSIs - Represent the specific VRF instance on that router used by this IPVPN service.
- Network Service Endpoint NSIs - Anchor a VRF instance (service context) to the underlying network connectivity. This is the PE-side binding of the VPN service toward the customer.
All three layers are NSIs, each one is a CI created in the Network Service Instance (NSI) table (cmdb_ci_network_service_instance), but each plays a different role in the L3VPN architecture and requires a different set of custom attributes according to its role. At the same time, all three of them might require some common custom attributes to be added, which should be manageable and visible across all CIs of the Network Service Instance class.
For more information about the modeling concept of an MPLS Layer 3 VPN (L3VPN) service in TNI with the ‘Network Service Instance’ class, please refer to the following article: https://www.servicenow.com/community/telecom-articles/modeling-concept-of-an-mpls-layer-3-vpn-servic...
Use TNI Attribute Packs when… (see example ‘A’)
- The data is relevant only to a subset of CI records in the same class (vendor/model/role/type/function–specific), not to all of them.
- The attributes are optional and likely to change, or you need versioning (for example, VRF_QoS_Pack_v1 for VRFs running older NOS versions and VRF_QoS_Pack_v2 for VRFs on newer NOS versions).
- You want granular management of CI attributes - packs are a collection of attributes you can associate with specific CIs. You can attach multiple packs to the same CI record.
- You want zero schema impact on the CI table: define a pack table (extending sn_attribute_pack_base), configure it for the target CI class with Pack Config (with filter conditions), and then admins attach the pack to the CI record.
- If you’re okay with filtering, reporting, or querying on pack table data being done separately from the CI that this pack is attached to, no customization is needed. If you require that some selected data (specific columns) from the pack table should still be visible and queryable from the OOB table of the CI this pack is assigned to, as if it were a native column, this will require some customization. This includes adding a reference on the CI's OOB table, dot-walking from the OOB table to the pack table column, using advanced qualifiers to locate the specific field belonging to a specific CI record, and implementing synchronization business rule(s) to keep the data persistent in the CMDB and synchronize the views.
Benefits: ServiceNow TNI Attribute Packs let you attach a reusable collection of user-defined attributes to only the subset of CI records that need them, enabling more granular management of CI data.
Add custom fields on OOB tables when… (see example ‘B’)
- The data needed is common for all CI records of that class and you want to manage it.
- The attribute must live on the CI class itself (for example, it’s used by Identification & Reconciliation rules to uniquely identify or reconcile the CI).
- It must be queryable/reportable/indexable for dashboards and filters.
Example A - VRF Attribute Pack (attached to a Network Service Instance class CI that represents a VRF instance)
- Pack table: your pack (extends sn_attribute_pack_base table). You define the attributes, then map the pack to the NSI table with a filter so it’s available only on VRF NSIs (subset), and use it on the CI record.
- Scope rule: Pack Config > Configuration Item = cmdb_ci_network_service_instance. Filter = your condition that marks VRF NSIs (so the pack appears only there). (Packs are intended for a subset of CI records.)
- Example pack name: VRF_Attributes_Pack
- Example attributes (customer-defined, VRF-only):
- vrf_rd - 65000:123
- vrf_rt_import - 65000:100, 65000:200
- vrf_rt_export - 65000:300
- vrf_af - ipv4
- vrf_max_routes - 100000
These are example data columns appropriate to a VRF context and not relevant to the global L3VPN service NSI or to network service endpoint NSIs, exactly the kind of subset-only attributes to place in a pack.
Example B - Custom column on the OOB Network Service Instance table (applies universally across all CIs of the NSI class)
- Table: cmdb_ci_network_service_instance (every NSI you create is a CI in this table).
- Column (example): u_service_role (reference to trf_value table).
- Purpose: A classification of role/type/function used across all CIs of the NSI class (note that the trf_value table contains role/type/functions also used beyond the NSI class, but you can add NSI-specific roles to it, create it as a reference column on the NSI table. (cmdb_ci_network_service_instance) which references the trf_value table, and allow admins to assign a role/type/function to your NSI CIs.
- Example data values (from the diagram’s NSI layers):
- IPVPN_service - e.g., IPVPN_MGMT_SERVICE (top-level service NSI)
- VRF - e.g., VRF on PE-LON-1, VRF on PE-LON-2
- Network Service Endpoint - e.g., service-endpoint NSIs on each PE
Why this belongs as a column on the class: it’s universal across every NSI and you want it consistently filterable/reportable.
Implementers’ Notes, Tips and Useful Links
- The attributes are not discovered and are not part of CI identification or reconciliation logic. Discovery does not populate Attribute Pack tables out of the box (OOB). If, later on, you need Discovery to populate attributes in your custom Pack table, you must implement specific integration/ETL (transforming and mapping) and Identification and Reconciliation (IRE) logic.
- TNI Attributes Pack (do not forget to create it in the relevant application scope - Attribute Pack: https://www.servicenow.com/docs/bundle/zurich-telecom-network-inventory/page/product/tmt-telecom-net...
#TelecomNetworkInventory #TNI #AttributePack #Design #L3VPN
