As an ITSM administrator, I want to add a configurable third-level (tertiary) dynamic field associated with Category/Subcategory so that I can better classify tickets, improve routing accuracy, and enable more flexible reporting without hardcoding additional subcategories.
SWSD’s current Category → Subcategory model is too rigid. It forces overloading of subcategories to represent multiple dimensions (service type, asset, issue type, environment), which leads to:
- bloated and hard-to-maintain subcategory lists
- inconsistent classification across teams
- limited ability to drive automation without creating excessive triggers
- poor reporting fidelity due to mixed semantics in a single field
This contrasts with platforms like Zendesk or ManageEngine that support more flexible schemas (e.g., dependent fields, dynamic dropdowns, or custom objects).
Introduce a tertiary field that is:
- dynamically tied to Category and Subcategory
- configurable per service domain (not global-only)
- usable in workflows, routing rules, SLAs, and reporting
- optionally required based on context
This field should behave similarly to a dependent dropdown or schema-driven attribute.
Current state:
You’re trying to model something like:
- Category: Hardware
- Subcategory: Laptop
But now you need to differentiate:
- Issue Type (Broken Screen, Battery, Performance)
- Ownership/Routing (Service Desk vs Endpoint Team)
- Reporting dimension (Failure type vs lifecycle vs user error)
To make this work today, you’re forced to create subcategories like:
- Laptop – Broken Screen
- Laptop – Battery
- Laptop – Performance
- Laptop – Other
With a tertiary field:
- Category: Hardware
- Subcategory: Laptop
- Tertiary Field (Issue Type):
- Broken Screen
- Battery
- Performance
- Other
