ConfigType

ConfigType is a catalog that groups related configuration into clear, navigable sections
(e.g., SD-WAN, Customer Ticket, RPA Automation). It complements Modules by offering a taxonomy for forms, processes, registers, listings, notifications, and widgets so that admin tools (Backup/Restorer, tSM Studio) can filter, migrate, and audit configuration in a controlled way.

Why it matters

Organization & discoverability — find all assets for a domain quickly.
Scoped operations — export/restore or compare only what belongs to a given area.
Lifecycle control — use validity windows and tags to phase changes per environment or package.
Deployment discipline — choose a sync method to define how config moves from staging to production.

Tip: Use Module to express business capability ownership, and ConfigType to express the configuration bundle within/around that capability.

Typical Uses

Separate customer-service vs. field-service configurations (CustomerTicket, FieldOps).
Drive Backup / Restorer selections: “Restore only CRM-* and Ticketing types.”
Power tSM Studio filters to navigate large installations by domain.

Reference

ConfigType (attributes)

Field	Type	Required	Read-only	Description / Notes
`id`	UUID	–	–	Identifier (not for end-user display).
`code`	String	Yes	–	Unique ASCII code (no spaces). Used in references, filters, and tooling.
`name`	String	Yes	–	Human-readable name shown in admin UI.
`description`	String	–	–	Longer help text/tool-tip.
`validityFrom/To`	Date	–	–	Active window for this config group.
`valid`	Bool	–	Yes	Computed from validity; not stored.
`syncMethod`	Enum	Yes	–	How configs under this type are promoted between environments (see below).
`tsmModule`	String	–	–	Code of the Module this group belongs to (for ownership/routing).
`parent`	String	–	–	Optional hierarchical parent `ConfigType.code` (build trees like `CRM` → `CRM-Lead`).
`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.

Examples

Ticketing — core ticket forms, workflows, SLA registers, comment/notification presets.
Ticketing-ServiceAssurance (parent: Ticketing) — NOC incident specifics.
CRM — customer/account forms, dedup rules, interaction types.
CRM-Lead (parent: CRM) — lead stages, scoring, capture forms.
Integrations-SAP — interface definitions, mapping registries, retry policies.

Good Practices

Stable codes — pick short, semantic codes (Ticketing, CRM-Lead); changing them breaks references and filters.
Use hierarchy (parent) to mirror your domain tree and simplify bulk operations.
Choose syncMethod deliberately —
- use COMPARE where you expect frequent, controlled promotion from UAT;
- keep SYSTEM for platform-owned areas;
- avoid NONE unless divergence is a conscious requirement.
Tag consistently — dataTags like core, external, pilot help dashboards and access policies.
Keep config lean — store only metadata that helps tooling; operational knobs belong to deployment (e.g., Kubernetes).
Leverage validity — phase in/out large configuration packages during rollouts without dropping data.

Typical Uses​

Reference​

ConfigType (attributes)​

syncMethod semantics​

Examples​

Good Practices​

See Also​