ConfigType

ConfigType is a business-friendly packaging catalog that lets you organize tSM configuration into clear, navigable sections (for example: Ordering, Ordering.SDWAN, Ticketing.CustomerTicket, Integrations.SAP). It helps teams quickly find what belongs together, understand who owns it, and scope admin operations (filtering, auditing, backup/restore selections, studio navigation) to a specific area.

ConfigType is intended to group any mix of configuration assets—forms, processes, registers, listings, notifications, widgets, scripts, and other configuration types—under a single “package-like” node.

---

Why it matters

• Organization & discoverability — quickly find all assets for a domain/product area.
• Scoped operations — filter, audit, compare, export/restore only what belongs to a given area.
• Lifecycle control — validity windows and tags can help manage configuration over time.
• Clear ownership — make responsibility explicit at the package level (team ownership, stewards, approvals).

---

How ConfigType is used by configuration entities

All configuration entities in tSM contain a property:

• configType (String) — holds the ConfigType code.

This makes ConfigType the common “routing key” for:

• UI navigation (grouping and filtering)
• audit views (“who owns what”)
• packaging scope (“what belongs to this area”)

---

Hierarchical codes

ConfigType code is hierarchical by design.

Rule

A child ConfigType code MUST include the full code of all its parents as a prefix.

• A parent–child relationship is valid only if: child.code = parent.code + "." + <segment> (or the configured delimiter), and the child explicitly references that parent (see parent field below).

Examples

• cap.ordering

  • cap.ordering.catalog

  • cap.ordering.forms

  • cap.ordering.processes

  • cap.ordering.sdwan

    • cap.ordering.sdwan.catalog
    • cap.ordering.sdwan.forms
    • cap.ordering.sdwan.processes

This rule ensures that:

• the hierarchy is readable from the code itself,
• filtering by prefix is reliable (everything under cap.ordering.* is “Ordering”).

---

Typical uses

• Separate configuration areas by business domain or product line (e.g., cap.ticketing.*, cap.ordering.*, cap.ordering.sdwan.*).
• Power admin tooling selections (e.g., “restore only cap.ordering.* and cap.ticketing.*”).
• Navigate large installations in tSM Studio and admin UI by a stable taxonomy.

---

Reference

ConfigType (attributes)

Field	Type	Required	Read-only	Description / Notes
id	UUID	–	–	Identifier (not intended for end-user display).
code	String	Yes	–	Unique ASCII code (no spaces). Used in references, filters, and tooling. Must be hierarchical (includes parent codes).
name	String	Yes	–	Human-readable name shown in admin UI.
description	String	–	–	Longer help text / tool-tip.
parent	String	–	–	Optional hierarchical parent ConfigType.code. Used to build trees.
validityFrom/To	Date	–	–	Active window for this config group.
valid	Bool	–	Yes	Computed from validity; not stored.
syncMethod	Enum	Yes	–	Declares how configs under this type are promoted between environments (see below).
ownerTeam	String	Yes	–	Owner team responsible for the package and its contents.
stewards	List	–	–	Optional list of responsible individuals/roles for day-to-day curation.
approvers	List	–	–	Optional list of approvers used by governance workflows.
config	Map	–	–	Free-form metadata for admin tooling; keep it lightweight.
dataTags	List	–	–	Labels for dashboards/filters (e.g., core, pilot, external).
localizationData	Object	–	–	Translations for name / description.
auditInfo	Object	–	–	Standard audit metadata.

---

syncMethod semantics

• MANUAL — default; admins export/import explicitly.
• NONE — environments diverge intentionally; no cross-env sync.
• COMPARE — changes originate in test/UAT; promotion uses diff & apply workflows.
• SYSTEM — platform-critical configs; typically updated with application releases.

---

End-to-end example: Ordering vs SD-WAN-specific configuration

This example shows how to keep generic Ordering assets under Ordering packages, while placing SD-WAN-specific assets into a dedicated sub-package under Ordering.

ConfigType tree (packages)

Code	Name	Parent	Owner team	Purpose
cap.ordering	Ordering	–	Ordering Team	Root for ordering capability configuration.
cap.ordering.catalog	Ordering / Catalog	cap.ordering	Ordering Team	Shared catalog patterns, generic offerings/templates.
cap.ordering.forms	Ordering / Forms	cap.ordering	Ordering Team	Generic ordering forms and reusable fragments.
cap.ordering.processes	Ordering / Processes	cap.ordering	Ordering Team	Generic order lifecycle processes (validation, submission, cancellation).
cap.ordering.sdwan	Ordering / SD-WAN	cap.ordering	SD-WAN Solution Team	SD-WAN-specific ordering configuration.
cap.ordering.sdwan.catalog	Ordering / SD-WAN / Catalog	cap.ordering.sdwan	SD-WAN Solution Team	SD-WAN product catalog records and SD-WAN-specific attributes.
cap.ordering.sdwan.forms	Ordering / SD-WAN / Forms	cap.ordering.sdwan	SD-WAN Solution Team	SD-WAN-specific order capture wizards/forms.
cap.ordering.sdwan.processes	Ordering / SD-WAN / Processes	cap.ordering.sdwan	SD-WAN Solution Team	SD-WAN-specific orchestration steps in ordering processes.

How configuration entities are assigned

All relevant entities store configType as the code of the owning package:

Entity type	Example item	configType	Notes
Catalog record	“Generic Broadband Offer Template”	cap.ordering.catalog	Reused across products.
Form	“Generic Order Header”	cap.ordering.forms	Base order form used widely.
Process	“Order Submit (Generic)”	cap.ordering.processes	Shared ordering lifecycle.
Catalog record	“SD-WAN Offer”	cap.ordering.sdwan.catalog	SD-WAN-specific commercial and technical attributes.
Form / wizard	“SD-WAN Site Setup Wizard”	cap.ordering.sdwan.forms	SD-WAN-specific fields, validations, and UI steps.
Process	“SD-WAN Provisioning Orchestration”	cap.ordering.sdwan.processes	Product-specific flow pieces integrated into ordering.
Script / rule	“SD-WAN Eligibility Check”	cap.ordering.sdwan.processes (or cap.ordering.sdwan)	Kept with the domain where it is primarily maintained.
Register	“SD-WAN Device Models”	cap.ordering.sdwan.catalog	Product-specific reference data for catalog and ordering.

This structure keeps:

• Ordering fundamentals centralized under cap.ordering.*
• SD-WAN specifics isolated under cap.ordering.sdwan.*, with clear ownership and a clean navigation scope

---

Renaming and stability

ConfigType codes are used in references, filters, and tooling; changing them can break references and selections. Because all configuration entities store the owning package code in their configType property, renaming a ConfigType can have a large impact across all configuration that belongs to it (and all descendants, if renamed). The system will attempt to re-link affected configuration items, but renames should be performed very carefully, with full awareness of the scope of impacted assets.